Date: Wed, 21 Nov 2018 17:15:18 +0100 From: Ondřej Jirman <megous@...ous.com> To: musl@...ts.openwall.com Subject: Re: [RFC PATCH] Fix __libc_start_main prototype in [r]crt1.c to match the caller On Wed, Nov 21, 2018 at 04:22:17PM +0100, Szabolcs Nagy wrote: > * Szabolcs Nagy <nsz@...t70.net> [2018-11-21 16:09:04 +0100]: > > > * megous@...ous.com <megous@...ous.com> [2018-11-21 15:51:50 +0100]: > > > From: Ondrej Jirman <megous@...ous.com> > > > > > > __libc_start_main function is not using the last three arguments. > > > GCC in LTO mode complains about mismatch. > > > > fix it in the other way then. > > > > > - __libc_start_main(main, argc, argv, _init, _fini, 0); > > > + __libc_start_main(main, argc, argv); > > > > you just completely broke everything there didnt you? > > > > sorry the _init, _fini there is only needed for glibc compat > (i.e. executable linked with musl crt1.o, but using glibc > to run it, which should not be a common use case) I had a hunch that there was some reason outside of musl for these arguments, therefore just the RFC. I guess, it's better to ignore the patch then. I just saw a difference of prototypes, so I sent the patch. > > how will the _init/_fini code of executables with > > DT_INIT, DT_FINI dynamic tags run? > > > > i think gcc still havent fixed weak object symbol alias > > bugs with lto so e.g. you will get incorrect environ if > > you lto link the libc. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271 > > these lto issues still apply. I'm attempting a static build, for which this issue should not apply, AFAIK. Though, I'm trying on mips, and it leads to GOT related error. So LTO of musl+my code doesn't work anyway, because ld fails. I'll try with some other target just to see if I can get something that works, without the limitations of mips arch. regards, o.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.