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} }, 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 [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 >