Re: Glibc building procedure error report.
I am having some problems with building the libpthread addon. I get the error ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER -- but I can't seem to find this ^ ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:46:33: note: in expansion of macro '_HURD_THREADVAR_THREAD' __hurd_threadvar_location (_HURD_THREADVAR_THREAD);\ ^ ./pthread/../sysdeps/generic/pt-barrier-wait.c:52:32: note: in expansion of macro '_pthread_self' struct __pthread *self = _pthread_self (); I searched the source files for the macros '_HURD_THREADVAR_DYNAMIC_USER' and '_HURD_THREADVAR_THREAD' and I can't seem to find them so where are they used? I noticed '_HURD_THREADVAR_DYNAMIC_USER' used to be in /hurd/hurd/threadvar.h but now it's removed. Any ideas?
Re: Glibc building procedure error report.
Manolis Ragkousis, le Mon 07 Apr 2014 19:49:02 +, a écrit : I am having some problems with building the libpthread addon. I get the error ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) Which version of libpthread is this? I don't have this in my copy of the tree. We got rid of these a long time ago. Samuel
Re: Glibc building procedure error report.
2014-04-07 21:05 GMT+00:00 Samuel Thibault samuel.thiba...@gnu.org: Which version of libpthread is this? I don't have this in my copy of the tree. We got rid of these a long time ago. I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44
Re: Glibc building procedure error report.
Manolis Ragkousis, le Mon 07 Apr 2014 21:11:40 +, a écrit : 2014-04-07 21:05 GMT+00:00 Samuel Thibault samuel.thiba...@gnu.org: Which version of libpthread is this? I don't have this in my copy of the tree. We got rid of these a long time ago. I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44 Well, there's something fishy in there: in my clone ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:46 is __mach_port_deallocate (__mach_task_self (), ktid);\ and there is no occurrence of threadvar in the tree. Samuel
Re: Glibc building procedure error report.
Samuel Thibault samuel.thiba...@gnu.org skribis:
Manolis Ragkousis, le Wed 02 Apr 2014 00:29:13 +, a écrit :
/../build/libc_pic.os: In function `__fork':
/../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to
`__start__hurd_atfork_prepare_hook'
/../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld:
/../build/libc_pic.os: relocation R_386_GOTOFF against undefined hidden
symbol `__start__hurd_atfork_prepare_hook' can not be used when making a
shared object
/../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status
../Makerules:614: recipe for target '/../build/libc.so' failed
make[2]: ***
[/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/build/libc.so]
Error 1
make[2]: Leaving directory
'/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/source/elf'
Makefile:233: recipe for target 'elf/subdir_lib' failed
I searched the source files in posix and sysdeps/mach/hurd/ and I
can't seem to find any reference to
`__start__hurd_atfork_prepare_hook'.
Any ideas?
In such cases, look for subparts of the name, here atfork_prepare, and
you'll see
sysdeps/mach/hurd/fork.c:DEFINE_HOOK (_hurd_atfork_prepare_hook, (void));
The symbol is supposed to be defined automagically by the linker. I
don't know how exactly.
The linker magic is in the shlib.lds rules of Makerules, added in commit
56798c44 of glibc/Savannah.
However, it adds the start/stop symbols for the hurd_fork hooks, but not
for the hurd_atfork hooks. Do we need something like this:
diff --git a/Makerules b/Makerules
index fe967ad..cbf1b39 100644
--- a/Makerules
+++ b/Makerules
@@ -506,6 +506,15 @@ $(common-objpfx)shlib.lds: $(common-objpfx)config.make $(..)Makerules
PROVIDE(__start__hurd_preinit_hook = .);\
_hurd_preinit_hook : { *(_hurd_preinit_hook) }\
PROVIDE(__stop__hurd_preinit_hook = .);\
+ PROVIDE(__start__hurd_atfork_prepare_hook = .);\
+ _hurd_atfork_prepare_hook : { *(_hurd_atfork_prepare_hook) }\
+ PROVIDE(__stop__hurd_atfork_prepare_hook = .);\
+ PROVIDE(__start__hurd_atfork_child_hook = .);\
+ _hurd_atfork_child_hook : { *(_hurd_atfork_child_hook) }\
+ PROVIDE(__stop__hurd_atfork_child_hook = .);\
+ PROVIDE(__start__hurd_atfork_parent_hook = .);\
+ _hurd_atfork_parent_hook : { *(_hurd_atfork_parent_hook) }\
+ PROVIDE(__stop__hurd_atfork_parent_hook = .);\
PROVIDE(__start__hurd_fork_prepare_hook = .);\
_hurd_fork_prepare_hook : { *(_hurd_fork_prepare_hook) }\
PROVIDE(__stop__hurd_fork_prepare_hook = .);\
Thanks,
Ludo’.
Re: Glibc building procedure error report.
However, it adds the start/stop symbols for the hurd_fork hooks, but not
for the hurd_atfork hooks. Do we need something like this:
I added the following lines to the shlib.lds part of Makerules so I
can bypass the problem and it seems to work.
+PROVIDE(__start__hurd_atfork_prepare_hook = .);\
+_hurd_atfork_prepare_hook : { *(_hurd_atfork_prepare_hook) }\
+PROVIDE(__stop__hurd_atfork_prepare_hook = .);\
+PROVIDE(__start__hurd_atfork_child_hook = .);\
+_hurd_atfork_child_hook : { *(_hurd_atfork_child_hook) }\
+PROVIDE(__stop__hurd_atfork_child_hook = .);\
+PROVIDE(__start__hurd_atfork_parent_hook = .);\
+_hurd_atfork_parent_hook : { *(_hurd_atfork_parent_hook) }\
+PROVIDE(__stop__hurd_atfork_parent_hook = .);\
Re: Glibc building procedure error report.
Manolis Ragkousis, le Thu 03 Apr 2014 23:14:49 +, a écrit : Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should have made the build system take the libpthread/sysdeps path into account (at least in the Debian package it does). It takes into account the libpthread/sysdeps tree path. I have pasted the corresponding output of the configure script in the link below. http://paste.debian.net/plain/91552 The error appears when we include bits/(filename).h. It just looks for the headers in the bits/ folder, while they are at libpthread/sysdeps/generic/bits/. Well, there is some step during glibc configure which computes the list of such paths, see checking sysdep dirs..., libpthread/sysdeps/generic/bits should be among them. Samuel
Re: Glibc building procedure error report.
Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should
have made the build system take the libpthread/sysdeps path into account
(at least in the Debian package it does).
It takes into account the libpthread/sysdeps tree path. I have pasted
the corresponding output of the configure script in the link below.
http://paste.debian.net/plain/91552
The error appears when we include bits/(filename).h. It just looks
for the headers in the bits/ folder, while they are at
libpthread/sysdeps/generic/bits/.
A workaround is to add lines in Makerules just like there are for
*__libc_thread_subfreeres
There are already lines in Makerules for that.
PROVIDE(__start__hurd_fork_parent_hook = .);\
_hurd_fork_parent_hook : { *(_hurd_fork_parent_hook) }\
I am investigating if everything works as it should in my environment.
I have attached the output of the configure part of the building
process, so you can have a better look.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... i686-pc-gnu
checking for i686-pc-gnu-gcc... i686-pc-gnu-gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-gnu-gcc accepts -g... yes
checking for gcc... gcc
checking for i686-pc-gnu-g++... no
checking for i686-pc-gnu-c++... no
checking for i686-pc-gnu-gpp... no
checking for i686-pc-gnu-aCC... no
checking for i686-pc-gnu-CC... no
checking for i686-pc-gnu-cxx... no
checking for i686-pc-gnu-cc++... no
checking for i686-pc-gnu-cl.exe... no
checking for i686-pc-gnu-FCC... no
checking for i686-pc-gnu-KCC... no
checking for i686-pc-gnu-RCC... no
checking for i686-pc-gnu-xlC_r... no
checking for i686-pc-gnu-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for i686-pc-gnu-readelf... i686-pc-gnu-readelf
checking for sysdeps preconfigure fragments... x86_64
configure: running configure fragment for add-on libidn
configure: running configure fragment for add-on libpthread
configure: running configure fragment for add-on nptl
checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm hppa
ia64 m68k microblaze mips tile
checking for assembler and linker STT_GNU_IFUNC support... yes
checking whether .text pseudo-op must be used... yes
checking sysdep dirs... libpthread/sysdeps/mach/hurd/i386
sysdeps/mach/hurd/i386 libpthread/sysdeps/mach/hurd libpthread/sysdeps/hurd
sysdeps/mach/hurd sysdeps/gnu sysdeps/unix/bsd/bsd4.4 sysdeps/mach/i386
libpthread/sysdeps/mach sysdeps/mach sysdeps/i386/i686/fpu sysdeps/i386/i686
sysdeps/i386/i486 sysdeps/i386/fpu sysdeps/x86/fpu libpthread/sysdeps/i386
sysdeps/i386 sysdeps/x86 sysdeps/wordsize-32 sysdeps/ieee754/ldbl-96
sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/unix/bsd
sysdeps/unix/inet sysdeps/ieee754 sysdeps/unix sysdeps/posix
libpthread/sysdeps/posix sysdeps/generic
configure: WARNING: add-on ports contributed no sysdeps directories
checking for a BSD-compatible install...
/gnu/store/gjl05yl9lvgjhznz5v985mys861svp34-coreutils-8.21/bin/install -c
checking whether ln -s works... yes
checking whether
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as
is GNU as... yes
checking whether
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld
is GNU ld... yes
checking for
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as...
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as
checking version of
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/as...
2.23.2, ok
checking for
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld...
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld
checking version of
/gnu/store/hl1rsbjzq5pwph850al9y52xrjqjg4f5-gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld...
2.23.2, ok
checking for i686-pc-gnu-gcc... (cached) i686-pc-gnu-gcc
checking version of i686-pc-gnu-gcc... 4.8.2, ok
checking for gnumake... no
checking for gmake... no
checking for make... make
checking version of make... 4.0, ok
checking for gnumsgfmt... no
checking for gmsgfmt... no
checking for msgfmt... no
checking for makeinfo... no
checking for sed... sed
checking version of sed... 4.2.2, ok
checking for gawk... gawk
checking version of gawk... 4.1.0, ok
checking for i686-pc-gnu-nm... i686-pc-gnu-nm
checking for autoconf... autoconf
checking whether autoconf works... yes
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: msgfmt
makeinfo
*** some features will be disabled.
*** Check the INSTALL file for
Re: Glibc building procedure error report.
Manolis Ragkousis, le Mon 31 Mar 2014 22:35:08 +, a écrit : I came across on some issues in the building procedure which are not solved in the debian patches so I think I should report them, ask for comments on them and be as solid as possible in my descriptions. First there are 2 definitions of sigset_t One in (path_to_glibc)/libpthread/signal/signal.h typedef uint64_t sigset_t; and one in (path_to_glibc)/misc/sys/select.h typedef __sigset_t sigset_t; The build procedure fails if I don't comment one of them out. This is actually fixed by the Debian patch libpthread_clean.diff That being said, are the files in signal/ really useful at all anymore? Secondly the building procedure was looking for the header files located in (path_to_glibc)/libpthread/sysdeps/generic/bits in the (path_to_glibc)/bits so I had to copy them there manually. Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should have made the build system take the libpthread/sysdeps path into account (at least in the Debian package it does). And finally I get the error collect2: error: ld returned 1 exit status in this part here make[4]: Entering directory '/../source/hurd' /../build/libc_pic.a(sigsetops.os): In function `__spin_unlock': /../source/signal/../sysdeps/mach/i386/machine-lock.h:44: multiple definition of `__spin_unlock' /../build/libc_pic.a(spin-lock.os):/tmp/ nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/ i386/machine-lock.h:44: first defined here I also wonder how that can be. _EXTERN_INLINE is precisely meant to avoid this issue: either the definition is inlined in the caller, or an external definition is emitted. Maybe you should check what _EXTERN_INLINE gets defined to, it should be extern inline in the end. Samuel
Re: Glibc building procedure error report.
As I said in the irc I managed to bypass the previous error by deleting #define _EXTERN_INLINE in signal/sigsetops.c I am now getting the error /../build/libc_pic.os: In function `__fork': /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to `__start__hurd_atfork_prepare_hook' /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: /../build/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: final link failed: Bad value collect2: error: ld returned 1 exit status ../Makerules:614: recipe for target '/../build/libc.so' failed make[2]: *** [/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/build/libc.so] Error 1 make[2]: Leaving directory '/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/source/elf' Makefile:233: recipe for target 'elf/subdir_lib' failed I searched the source files in posix and sysdeps/mach/hurd/ and I can't seem to find any reference to `__start__hurd_atfork_prepare_hook'. Any ideas? Manolis
Re: Glibc building procedure error report.
Manolis Ragkousis, le Wed 02 Apr 2014 00:29:13 +, a écrit : /../build/libc_pic.os: In function `__fork': /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to `__start__hurd_atfork_prepare_hook' /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: /../build/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-gnu/ld: final link failed: Bad value collect2: error: ld returned 1 exit status ../Makerules:614: recipe for target '/../build/libc.so' failed make[2]: *** [/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/build/libc.so] Error 1 make[2]: Leaving directory '/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-38/source/elf' Makefile:233: recipe for target 'elf/subdir_lib' failed I searched the source files in posix and sysdeps/mach/hurd/ and I can't seem to find any reference to `__start__hurd_atfork_prepare_hook'. Any ideas? In such cases, look for subparts of the name, here atfork_prepare, and you'll see sysdeps/mach/hurd/fork.c:DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); The symbol is supposed to be defined automagically by the linker. I don't know how exactly. A workaround is to add lines in Makerules just like there are for *__libc_thread_subfreeres, but it'd be very good to investigate what is not working in your environment. Samuel
Glibc building procedure error report.
I came across on some issues in the building procedure which are not solved in the debian patches so I think I should report them, ask for comments on them and be as solid as possible in my descriptions. First there are 2 definitions of sigset_t One in (path_to_glibc)/libpthread/signal/signal.h typedef uint64_t sigset_t; and one in (path_to_glibc)/misc/sys/select.h typedef __sigset_t sigset_t; The build procedure fails if I don't comment one of them out. Secondly the building procedure was looking for the header files located in (path_to_glibc)/libpthread/sysdeps/generic/bits in the (path_to_glibc)/bits so I had to copy them there manually. And finally I get the error collect2: error: ld returned 1 exit status in this part here make[4]: Entering directory '/../source/hurd' /../build/libc_pic.a(sigsetops.os): In function `__spin_unlock': /../source/signal/../sysdeps/mach/i386/machine-lock.h:44: multiple definition of `__spin_unlock' /../build/libc_pic.a(spin-lock.os):/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/i386/machine-lock.h:44: first defined here /../build/libc_pic.a(sigsetops.os): In function `__spin_try_lock': /../source/signal/../sysdeps/mach/i386/machine-lock.h:59: multiple definition of `__spin_try_lock' /../build/libc_pic.a(spin-lock.os):/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/i386/machine-lock.h:59: first defined here /../build/libc_pic.a(sigsetops.os): In function `__spin_lock_locked': /../source/signal/../sysdeps/mach/i386/machine-lock.h:74: multiple definition of `__spin_lock_locked' /../build/libc_pic.a(spin-lock.os):/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/source/mach/../sysdeps/mach/i386/machine-lock.h:74: first defined here collect2: error: ld returned 1 exit status ../Makerules:589: recipe for target '/../build/libc_pic.os' failed make[2]: *** [/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-16/build/libc_pic.os] Error 1 I am working on solving this last one, but I would like any possible help. Manolis
