Re: Static linking of musl with code compiled using GNU header files

[David Grothe <dave@gcom.com>]

[-- Attachment #1: Type: text/plain, Size: 7695 bytes --]

I built a shim module that defined all the undefined "__" routines that 
showed up in my link.  Then all my programs linked successfully.  But 
when I went to run one of my daemon processes it got a segv in the 
malloc code, as follows.

Program terminated with signal 11, Segmentation fault.
#0  0x0811cd5d in unbin (c=0x9b53898, i=8) at src/malloc/malloc.c:242
#1  0x0811d266 in malloc (n=112) at src/malloc/malloc.c:371
#2  0x0804b3ce in ssd_malloc_fcn (nbytes=16, file=0x81348e6 "../pi.c", 
linenr=2398) at ../pi.c:632
#3  0x0804b597 in ssd_zalloc_fcn (nbytes=12, file=0x81348e6 "../pi.c", 
linenr=2398) at ../pi.c:687
#4  0x0804b5e2 in ssd_calloc_fcn (n_memb=1, memb_size=12, file=0x81348e6 
"../pi.c", linenr=2398) at ../pi.c:696
#5  0x0804ef18 in ss_setup_code_path (size=1024) at ../pi.c:2398
#6  0x080548be in register_connections () at ../pi.c:5074
#7  0x0805a2b8 in main (argc=2, argv=0xbfae15f4) at ../pi.c:7393
(gdb) p *c
$1 = {psize = 17, csize = 144, next = 0x81a3990, prev = 0x1}
(gdb) p mal
$2 = {brk = 163028992, heap = 0x9b53008, binmap = 35184372089088, bins = 
{{lock = {0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0}, head = 
0x81a3920, tail = 0x81a3920}, {lock = {0, 0},
       head = 0x81a3930, tail = 0x81a3930}, {lock = {0, 0}, head = 
0x81a3940, tail = 0x81a3940}, {lock = {0, 0}, head = 0x0, tail = 0x0}, 
{lock = {0, 0}, head = 0x81a3960, tail = 0x81a3960}, {
       lock = {0, 0}, head = 0x81a3970, tail = 0x81a3970}, {lock = {0, 
0}, head = 0x81a3980, tail = 0x81a3980}, {lock = {0, 0}, head = 
0x9b53898, tail = 0x9b53898}, {lock = {0, 0},
       head = 0x81a39a0, tail = 0x81a39a0}, {lock = {0, 0}, head = 
0x81a39b0, tail = 0x81a39b0}, {lock = {0, 0}, head = 0x81a39c0, tail = 
0x81a39c0}, {lock = {0, 0}, head = 0x81a39d0,
       tail = 0x81a39d0}, {lock = {0, 0}, head = 0x81a39e0, tail = 
0x81a39e0}, {lock = {0, 0}, head = 0x81a39f0, tail = 0x81a39f0}, {lock = 
{0, 0}, head = 0x81a3a00, tail = 0x81a3a00}, {lock = {0,
         0}, head = 0x81a3a10, tail = 0x81a3a10}, {lock = {0, 0}, head = 
0x0, tail = 0x0}, {lock = {0, 0}, head = 0x81a3a30, tail = 0x81a3a30}, 
{lock = {0, 0}, head = 0x81a3a40, tail = 0x81a3a40},
     {lock = {0, 0}, head = 0x81a3a50, tail = 0x81a3a50}, {lock = {0, 
0}, head = 0x81a3a60, tail = 0x81a3a60}, {lock = {0, 0}, head = 0x0, 
tail = 0x0}, {lock = {0, 0}, head = 0x81a3a80,
       tail = 0x81a3a80}, {lock = {0, 0}, head = 0x81a3a90, tail = 
0x81a3a90}, {lock = {0, 0}, head = 0x81a3aa0, tail = 0x81a3aa0}, {lock = 
{0, 0}, head = 0x0, tail = 0x0}, {lock = {0, 0},
       head = 0x81a3ac0, tail = 0x81a3ac0}, {lock = {0, 0}, head = 
0x81a3ad0, tail = 0x81a3ad0}, {lock = {0, 0}, head = 0x81a3ae0, tail = 
0x81a3ae0}, {lock = {0, 0}, head = 0x81a3af0,
       tail = 0x81a3af0}, {lock = {0, 0}, head = 0x0, tail = 0x0}, {lock 
= {0, 0}, head = 0x81a3b10, tail = 0x81a3b10}, {lock = {0, 0}, head = 
0x81a3b20, tail = 0x81a3b20}, {lock = {0, 0},
       head = 0x81a3b30, tail = 0x81a3b30}, {lock = {0, 0}, head = 
0x81a3b40, tail = 0x81a3b40}, {lock = {0, 0}, head = 0x81a3b50, tail = 
0x81a3b50}, {lock = {0, 0}, head = 0x81a3b60,
       tail = 0x81a3b60}, {lock = {0, 0}, head = 0x81a3b70, tail = 
0x81a3b70}, {lock = {0, 0}, head = 0x81a3b80, tail = 0x81a3b80}, {lock = 
{0, 0}, head = 0x81a3b90, tail = 0x81a3b90}, {lock = {0,
         0}, head = 0x81a3ba0, tail = 0x81a3ba0}, {lock = {0, 0}, head = 
0x81a3bb0, tail = 0x81a3bb0}, {lock = {0, 0}, head = 0x81a3bc0, tail = 
0x81a3bc0}, {lock = {0, 0}, head = 0x81a3bd0,
       tail = 0x81a3bd0}, {lock = {0, 0}, head = 0x9b78888, tail = 
0x9b78888}, {lock = {0, 0}, head = 0x81a3bf0, tail = 0x81a3bf0}, {lock = 
{0, 0}, head = 0x0, tail = 0x0} <repeats 17 times>},
   brk_lock = {0, 0}, free_lock = {0, 0}}


I can supply more details as needed.
Thanks,
Dave


On 3/14/2014 1:52 PM, David Grothe wrote:
> Thanks for the suggestions.
>
> My musl build did not include a libgcc:
>
> linuxsvr:dave:musl-0.9.15> find . -name '*libgcc*'
> linuxsvr:dave:musl-0.9.15>
>
> It is correct that something in the GNU headers changed "signal" into 
> "sysv_signal" without my knowledge.
>
> My code base is several million lines of code and I have many other 
> projects to do that are higher priority than porting to another set of 
> header files.  It would be a few days worth of effort and I just have 
> other things to do right now.
>
> That said I do have a reason for wanting static linking, so maybe I 
> will find the time to do the port some time. (I tried just aiming my 
> build at the musl include directory and it did not "just work".)
>
> I can act on the suggestions made and see how that helps.  But what 
> about libgcc?
>
> Thanks,
> Dave
>
> On 3/14/2014 11:29 AM, Szabolcs Nagy wrote:
>> * David Grothe<dave@gcom.com>  [2014-03-14 10:47:31 -0500]:
>>> I have a very large code base that I have been compiling on Linux
>>> using the standard GNU C compiler [gcc (Ubuntu/Linaro
>>> 4.6.3-1ubuntu5) 4.6.3].  I have been using shared object libraries,
>>> but for reasons of software support I would now like to link all my
>>> commands (a couple of dozen) and daemons using static libraries so
>>> that the code files are self-contained and can be copied, along with
>>> a core file, to any server back in my shop for analysis.  With
>>> dynamic libraries I have to have exactly the same version of libc
>>> installed on the machine that I use to examine the core file as were
>>> present on the machine that generated the core file, or else gdb
>>> will not produce a stack back trace with file and line number
>>> information.  So much for the background.
>>>
>>> I really don't want to port my code base to using the musl header
>>> files.  I want to keep compiling with the GNU headers.  When I do
>> compiling with the gnu headers is broken and
>> it depends on the cflags used
>>
>>> this and link my-huge-program.o with musl libc.a I get the following
>>> list of unresolved externals:
>>>
>>>           U __divdi3
>> comes from libgcc.a, if it's missing you have a toolchain issue
>>
>>>           w __fini_array_end
>>>           w __fini_array_start
>> i think musl supports init/fini arrays
>> (see src/exit/exit.c)
>>
>>>           U __moddi3
>> libgcc
>>
>>>           U __sysv_signal
>> you may want to replace it with signal
>>
>>>           U __udivdi3
>>>           U __umoddi3
>> libgcc
>>
>>>           U __vfprintf_chk
>>>           U __vsnprintf_chk
>>>           U __vsprintf_chk
>> there are many _chk functions for _FORTIFY_SOURCE, musl may provide
>> these eventually, until then you can add your own chk.o with dummy
>> implementations (possibly with the safety checks i omit here):
>>
>> int __vfprintf_chk(FILE *f, int flag, const char *fmt, va_list ap)
>> {
>> 	return vfprintf(f, fmt, ap);
>> }
>> int __vsnprintf_chk(char *s, size_t n, int flag, size_t size, const char *fmt, va_list ap)
>> {
>> 	return vsnprintf(s, n, fmt, ap);
>> }
>> int __vsprintf_chk(char *s, int flag, size_t size, const char *fmt, va_list ap)
>> {
>> 	return vsprintf(s, fmt, ap);
>> }
>>
>>>           U __sysv_signal
>> use signal
>>
>>> So, I am wondering if the musl library could at some point provide
>>> these routines to enable users to do what I am trying to do.
>> compiling with glibc headers and then linking to musl
>> cannot be supported in general, because of ABI compat issues
>>
>> (eg glibc headers define PTHREAD_*_INITIALIZER macros that hardcode
>> glibc internal ABI at compile time that does not match musl)
>>
>> if you are sure you don't have such ABI breakage (see glibc
>> vs musl differences on the wiki) then you may get away by
>> adding a glibc-compat.o to your musl build
>>
>>> Any possibility of that?
>>>
>>> Thanks,
>>> Dave
>


[-- Attachment #2: Type: text/html, Size: 10449 bytes --]