mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: C++ program with no dependencies except musl
Date: Mon, 2 Oct 2017 12:50:33 +0200	[thread overview]
Message-ID: <20171002105033.GK15263@port70.net> (raw)
In-Reply-To: <626996737.38853.1506938734029@office.mailbox.org>

* Paul Kaletta <pk@paulkaletta.org> [2017-10-02 12:05:33 +0200]:
> I'm just getting started with musl, and have two questions.
> 
> On Arch Linux I installed the packages for musl (vesion 1.1.16-2), and
> gcc (version 7.2.0-2).
> 
> I have this program:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(void)
> {
>     printf("Hello!\n");
>     exit(0);
> }
> 
> I have stored it in justmain.c, and justmain.cpp.
> 
> I can easily compile it with:
> 
> $ musl-gcc -o justmain_static_c justmain.c -static
> 

musl-gcc is a hack to wrap the system gcc to make it use musl
instead of the system c library and drop the system -I and -L paths.

so your gcc is most likely configured against glibc not against
musl which can cause various issues:
- system libatomics.so may fail to load (it uses a gnu
extension that is only supported by the glibc dynamic loader.
matters if atomics are not inlined e.g. 16byte atomics is used)
- there may be symbol versioning issues (musl loader does not
support glibc compatible symbol versions, it affects libgcc_s.so
which is needed for c++ code for the unwinder)
- broken gthread which incorrectly detects single-threadedness
in case of static linking with libstdc++.
- different __*INT*_TYPE macro definitions than in libc headers
(most code should work fine, but some things might fail:
e.g. gfortran ffi calls into c functions using uint_fast16_t)
- many other details i dont remember now..

the recommended use of musl on a non-musl system is via a cross
toolchain that is built against musl (e.g.
https://github.com/richfelker/musl-cross-make
can build you one)

> However, when I do not want a dynamically linked library, I get an
> error:
> 
> $ musl-gcc -o justmain_dynamic_c justmain.c
> /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/crtbegin.o: relocation R_X86_64_32 against hidden symbol `__TMC_END__' can not be used when making a shared object
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> 
> The error goes away when I append the -pie, or -no-pie linker option
> to the build command line.  What is happening here, and why do both
> options work?
> 

the host gcc most likely defaults to pie, the musl-gcc wrapper
assumes traditional non-default-pie gcc (since that was the only
way to build gcc when musl-gcc was written).

i don't know if the musl-gcc specs file can be updated to support
both cases (the specs file does not know the default, only what
the user specified explicitly).

> For a little project of mine I would like to use C++ language
> features, but leave out the default C++ standard library.  I was also
> thinking about using musl together with tinystl
> (https://github.com/mendsley/tinystl), which is header-only.
> 
> I found some good sources (http://www.avabodh.com/cxxin/nostdlib.html,
> http://wiki.osdev.org/C%2B%2B,
> http://wiki.osdev.org/Calling_Global_Constructors), but I'm still
> figuring out how to apply the information to my use case.
> 
> I have a hard time with the basics already.  I can take the program
> from above and compile it as C++.
> 
> $ musl-gcc -std=c++11 -g -nostdlib -fno-exceptions -fno-rtti justmain.cpp -o justmain_cpp --entry main -L /usr/lib/musl/lib/ -lc
> 
> The resulting binary works.  When I add -static, I can compile
> succesfully, but the resulting binary gives me a segmentation fault.
> 
> $ musl-gcc -std=c++11 -g -nostdlib -fno-exceptions -fno-rtti justmain.cpp -o justmain_static_cpp --entry main -L /usr/lib/musl/lib/ -lc -static
> $ ./justmain_static_cpp 
> Segmentation fault (core dumped)
> 

if you use -nostdlib you have to be careful how you link,
since you jump directly to main without initializing the
libc things will break (crt*.o files are there for a reason..)

> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004002c1 in __overflow ()
> (gdb)
> 
> I'm not sure what exactly is happening, but I suspect that some global
> init function for musl was not called, which results in the observed
> behavior.
> 

you need to add the appropriate crt files (and specify
pie/no-pie)

> My goal is a minimal example of a C++ program that depends on musl and
> nothing else.  It would be nice if it could be linked both statically
> and dynamically.  I realize that some C++ language features will need
> some infrastructure that is normally provided by the C++ runtime
> library.  But as a first step: what is required to get the above
> program to compile (with a C++ compiler) to a statically linked binary
> that actually works?
> 
> Can I use the musl-gcc wrapper with -std=c++11 for my purpose, or do I
> need a more sophisticated approach?
> 

use a cross toolchain, with that, arbitrary c++11 code should
compile with both static and dynamic linking.

> Best regards,
> Paul


  reply	other threads:[~2017-10-02 10:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02 10:05 Paul Kaletta
2017-10-02 10:50 ` Szabolcs Nagy [this message]
2017-10-02 14:57   ` musl-cross-make doesn't install gcc binaries Didier Kryn
2017-10-02 15:57     ` Rich Felker
2017-10-03  8:11       ` Didier Kryn
2017-10-03  8:18         ` Didier Kryn
2017-10-03  9:37           ` Szabolcs Nagy
2017-10-03 10:38             ` Didier Kryn
2017-10-03 10:59               ` Szabolcs Nagy
2017-10-03 12:55                 ` Didier Kryn
2017-10-04 10:35                   ` Szabolcs Nagy
2017-10-04 19:27                     ` Didier Kryn

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=20171002105033.GK15263@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.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).