Hi everyone, I just manually copied libc.a and libpthread.a from /tools/lib to /lib and now I can compile libcap successfully. Now an ideal solution but seems to be working so far. Any other suggestions?
On Tue, 7 Jan 2020 at 22:17 Αγαθοκλής via lfs-dev < lfs-dev@lists.linuxfromscratch.org> wrote: > Hi Pierre, > > On Tue, Jan 07, at 09:19 Pierre Labastie via lfs-dev wrote: > > Le 06/01/2020 à 23:54, Αγαθοκλής via lfs-dev a écrit : > > > Hi Saul, > > > > > > On Tue, Jan 07, at 01:35 Saul Tigh via lfs-dev wrote: > > >> gcc -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Dlinux -Wall > > >> -Wwrite-strings -Wpointer-arith -Wcast-qual -Wcast-align > > >> -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline > -Wshadow > > >> -g -fPIC -I/usr/include > > >> -I/build_scripts/libcap/src/libcap-2.30/tests/../libcap/include > > >> libcap_psx_test.c -o libcap_psx_test > > >> -L/build_scripts/libcap/src/libcap-2.30/tests/../libcap -lcap > > >> -L/build_scripts/libcap/src/libcap-2.30/tests/../libcap -lpsx > -lpthread > > >> -Wl,-wrap,pthread_create --static > > >> /usr/bin/ld: cannot find -lpthread > > >> /usr/bin/ld: cannot find -lc > > >> collect2: error: ld returned 1 exit status > > > > > > Do you have the pthread static library? > > > > > > Also no need for -fPIC here. > > > I'm sorry to say that the above comment is plain wrong: > > No need to feel sorry! > > > - First, this part of the command comes from upstream, so there is > nothing we > > can do with it (the -I/usr/include part does not come from upstream, so > maybe > > it has something to do with the failure). And they work well at least in > my case. > > - Second, -fPIC *is* needed because the linker uses a shared library > rather > > than a static one if present, and there *is* a shared libcap library > > - Third, since -fPIC is used, it is possible to link with the shared > pthread > > library... > > What i know, is that the compiler doesn't have to produce position > independent > code for static executables, since those are loaded by the kernel in a > fixed > address and there is no need for rellocation, like say for shared > libraries, > as the linker does what it has to be done during linking. And the linker in > this case is looking for static objects. > > Also by looking at the output libcap.a and libpsx.a were created before, > which > is why the linker doesn't complain about. So most probably Saul has moved > away > both libc.a and libpthread.a. > > > Pierre > > Best, > Αγαθοκλής > -- > http://lists.linuxfromscratch.org/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
