Alright, I've checked everything again.
On 11/25/2012 05:37 PM, Pierre Labastie wrote:
> Hello,
>
> I know it has been reported by Tobias on lfs-support, but it seems to me
> it is an issue with the current version of check, and it should be
> addressed in the book:
> - the error occurs during make:
> ----------------------------
> /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I.. -O3 -pipe -march=native -Wall -ansi -pedantic -Wextra
> -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings
> -Wno-variadic-macros -MT putenv.lo -MD -MP -MF .deps/putenv.Tpo -c -o
> putenv.lo putenv.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -O3 -pipe -march=native
> -Wall -ansi -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes
> -Wwrite-strings -Wno-variadic-macros -MT putenv.lo -MD -MP -MF
> .deps/putenv.Tpo -c putenv.c -fPIC -DPIC -o .libs/putenv.o
> putenv.c:5:1: error: expected identifier or '(' before '{' token
> make[2]: *** [putenv.lo] Error 1
> make[2]: Leaving directory `/mnt/lfs/sources/check-0.9.9/lib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/mnt/lfs/sources/check-0.9.9'
> make: *** [all] Error 2
> ------------------------------
> The reason is clearly a syntax error in the file putenv.c :
> ----------------------
> > less lib/putenv.c
>
> #include "libcompat.h"
>
> int
> putenv (const char *string CK_ATTRIBUTE_UNUSED);
This is wrong. When function is defined there should not be ; at the
end. It should be only used when prototype is defined.
> {
> assert (0);
> return 0;
> }
> -------------------------
> On the other hand, this file should not be compiled, since it is a
> fallback if putenv is not present, but it is easy to check that putenv
> is in the glibc library. Now, in configure output, we have:
I've ran configure on my system (already built one) and most of these
are "yes"
checking for pipe... yes
checking for putenv... yes
checking for setenv... yes
checking for sleep... yes
checking for strdup... yes
checking for strsignal... yes
checking for unsetenv... yes
> --------------------------
> checking for pipe... no
> checking for putenv... no
> checking for setenv... no
> checking for sleep... no
> checking for strdup... no
> checking for strsignal... no
> checking for unsetenv... no
> --------------------------------
> and config.log has:
> -----------------------------
> configure:13124: checking for putenv
> configure:13124: gcc -o conftest -O3 -pipe -march=native -Wall -ansi
> -pedantic -Wextra -Wstrict-prototypes -Wmissing-prototypes
> -Wwrite-strings -Wno-variadic-macros conftest.c -lrt >&5
> conftest.c:71:1: warning: function declaration isn't a prototype
> [-Wstrict-prototypes]
> conftest.c:80:1: warning: function declaration isn't a prototype
> [-Wstrict-prototypes]
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../lib64/librt.so:
> undefined reference to `__pthread_get_minstack@GLIBC_PRIVATE'
> collect2: error: ld returned 1 exit status
> configure:13124: $? = 1
> ---------------------------------
> in fact, -lrt should not be used without -lpthread. Now, the reason I
> think is that configure has LIBS=-lrt too early, that is before testing
> the thread library. It is a bug, which I plan to report upstream.
>
Indeed, librt is linked to libpthread, but linker should pick it up. I
think that librt uses it's functions for it's threading and doesn't need
to expose any of libpthread functions like in your case.
> A workaround for now is to change the configure command:
> LDFLAGS=-lpthread ./configure --prefix=/tools
>
> I am amazed that nobody else has reported that: I use jhalfs on Debian
> sid (64 bit).
>
> Regards
> Pierre
>
Brr, Debian Sid ... I wonder if lfs toolchain has ever been tested with
Debian's multiarch setup?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
