From: David Grothe <dave@gcom.com>
To: musl@lists.openwall.com
Cc: Support at Gcom <support@Gcom.com>
Subject: Re: Static linking of musl with code compiled using GNU header files
Date: Fri, 14 Mar 2014 13:52:18 -0500 [thread overview]
Message-ID: <53234FE2.7040309@gcom.com> (raw)
In-Reply-To: <20140314162957.GB27448@port70.net>
[-- Attachment #1: Type: text/plain, Size: 3748 bytes --]
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: 5279 bytes --]
next prev parent reply other threads:[~2014-03-14 18:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 15:47 David Grothe
2014-03-14 16:09 ` Luca Barbato
2014-03-14 16:29 ` Szabolcs Nagy
2014-03-14 18:52 ` David Grothe [this message]
2014-03-14 19:25 ` Kurt H Maier
2014-03-14 19:35 ` David Grothe
2014-03-14 21:04 ` David Grothe
2014-03-14 21:37 ` John Spencer
2014-03-15 0:09 ` Rich Felker
2014-03-15 0:22 ` Rich Felker
2014-03-14 16:47 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53234FE2.7040309@gcom.com \
--to=dave@gcom.com \
--cc=musl@lists.openwall.com \
--cc=support@Gcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).