build-stage0 fails on fedora #355

Open
opened 7 years ago by henriqueleng · 10 comments
henriqueleng commented 7 years ago (Migrated from github.com)
Owner

Hi,
I'm returning to sabotage :), I got fedora 22 to build it. The version of gcc is 5.1.1 (I couldn't get an older), and I installed glibc-static.
It fails to build stage0_musl (in the moment of linking), the error message on the log is:
...
rm -f lib/libc.a
ar rc lib/libc.a src/aio/aio.o src/aio/aio_suspend.o src/aio/lio_listio.o src/complex/__cexp.o src/complex/__cexpf.o src/complex/cabs.o src/complex/cabsf.o src/comp$
ranlib lib/libc.a
/bin/ld: src/env/__init_tls.lo: relocation R_X86_64_PC32 against symbol `__libc' can not be used when making a shared object; recompile with -fPIC
/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
Makefile:149: recipe for target 'lib/libc.so' failed
make: *** [lib/libc.so] Error 1
make: *** Waiting for unfinished jobs....

I would like to solve this problem before trying to build in another distro, I couldn't figure why its showing up. Could you guys help?

Hi, I'm returning to sabotage :), I got fedora 22 to build it. The version of gcc is 5.1.1 (I couldn't get an older), and I installed glibc-static. It fails to build stage0_musl (in the moment of linking), the error message on the log is: ... rm -f lib/libc.a ar rc lib/libc.a src/aio/aio.o src/aio/aio_suspend.o src/aio/lio_listio.o src/complex/__cexp.o src/complex/__cexpf.o src/complex/cabs.o src/complex/cabsf.o src/comp$ ranlib lib/libc.a /bin/ld: src/env/__init_tls.lo: relocation R_X86_64_PC32 against symbol `__libc' can not be used when making a shared object; recompile with -fPIC /bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Makefile:149: recipe for target 'lib/libc.so' failed make: **\* [lib/libc.so] Error 1 make: **\* Waiting for unfinished jobs.... I would like to solve this problem before trying to build in another distro, I couldn't figure why its showing up. Could you guys help?
rofl0r commented 7 years ago (Migrated from github.com)
Owner

hmm maybe try adding -fPIC to the CFLAGS used by stage0_musl

hmm maybe try adding -fPIC to the CFLAGS used by stage0_musl
henriqueleng commented 7 years ago (Migrated from github.com)
Owner

added 'echo "CFLAGS += -fPIC" >> config.mak' to pkg/stage0_musl, and it still the same error.
Am I doing something wrong?

added 'echo "CFLAGS += -fPIC" >> config.mak' to pkg/stage0_musl, and it still the same error. Am I doing something wrong?
rofl0r commented 7 years ago (Migrated from github.com)
Owner

can you post the build log somewhere ? pastebin oslt

can you post the build log somewhere ? pastebin oslt
rofl0r commented 7 years ago (Migrated from github.com)
Owner

the error is possibly due to a parrallel build issue
see http://git.musl-libc.org/cgit/musl/commit/?id=d18cf76d73df8f9cc751d4b4ba5a635c70c0c645
as an easy fix you could change the line make -j$MAKE_THREADS to make -j1

the error is possibly due to a parrallel build issue see http://git.musl-libc.org/cgit/musl/commit/?id=d18cf76d73df8f9cc751d4b4ba5a635c70c0c645 as an easy fix you could change the line `make -j$MAKE_THREADS` to `make -j1`
henriqueleng commented 7 years ago (Migrated from github.com)
Owner

tried all this options and they didn't solved :(...
this is how I let stage0_musl file: http://pastebin.com/raw.php?i=7axnQH1G
you can see -j1, -fPIC and a sed command that remove '.SECONDARY:'
the error log(same than before): http://sprunge.us/RAJI

tried all this options and they didn't solved :(... this is how I let stage0_musl file: http://pastebin.com/raw.php?i=7axnQH1G you can see -j1, -fPIC and a sed command that remove '.SECONDARY:' the error log(same than before): http://sprunge.us/RAJI
richfelker commented 7 years ago (Migrated from github.com)
Owner

Here is the source of the problem:
src/internal/libc.c:10: warning: visibility attribute not supported in this configuration; ignored

For building a shared libc.so, musl requires support for visibility. Originally there were workarounds for the case where the compiler doesn't support it, but they were removed since builds without visibility support would necessarily have ABI-breakage-type bugs anyway.

Sabotage is using gcc 3.4.6 for the bootstrap, right? This versions supports visibility just fine, but probably does something stupid to break it when --disable-shared is used.

Here is the source of the problem: src/internal/libc.c:10: warning: visibility attribute not supported in this configuration; ignored For building a shared libc.so, musl requires support for visibility. Originally there were workarounds for the case where the compiler doesn't support it, but they were removed since builds without visibility support would necessarily have ABI-breakage-type bugs anyway. Sabotage is using gcc 3.4.6 for the bootstrap, right? This versions supports visibility just fine, but probably does something stupid to break it when --disable-shared is used.
henriqueleng commented 7 years ago (Migrated from github.com)
Owner

Can you recommend me another way to get sabotage compiled and running?

Can you recommend me another way to get sabotage compiled and running?
rofl0r commented 7 years ago (Migrated from github.com)
Owner

yes, you can use musl-cross to "crosscompile" stage1 like its described in the readme. then you can use enter-chroot as usual to build stuff in the chroot.

yes, you can use musl-cross to "crosscompile" stage1 like its described in the readme. then you can use enter-chroot as usual to build stuff in the chroot.
rofl0r commented 7 years ago (Migrated from github.com)
Owner

(note that your problem is quite weird; build-stage0 builds gcc3.4.6 and then compiles musl with it, so the result should be 100% reproducible. may it be that the binutils version of your system causes the issue ? or did you set A to something else (like i386) when you actually wanted to build for x86_64 ? could be helpful if you paste your config)

(note that your problem is quite weird; build-stage0 builds gcc3.4.6 and then compiles musl with it, so the result should be 100% reproducible. may it be that the binutils version of your system causes the issue ? or did you set A to something else (like i386) when you actually wanted to build for x86_64 ? could be helpful if you paste your config)
henriqueleng commented 7 years ago (Migrated from github.com)
Owner

I'm sure I didn't messed the config file, I retried the process lots of times.
Any way, I got ubuntu and compiled it without problems, couldn't wait for the solution on fedora. The gcc version here is 4.8.4.
If it was a compiler problem, this problem may appear here again in the future.

I'm sure I didn't messed the config file, I retried the process lots of times. Any way, I got ubuntu and compiled it without problems, couldn't wait for the solution on fedora. The gcc version here is 4.8.4. If it was a compiler problem, this problem may appear here again in the future.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sabotage-linux/sabotage#355
Loading…
There is no content yet.