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: [PATCHv2,HURD] Add fork hooks for pthread_atfork
Hi! Manolis has hit this issue again, http://news.gmane.org/find-root.php?message_id=%3CCAFtzXzNgS8KEwRJO74SF7zZPMnwFkW_m1qvir6y7-WNwaKEsWQ%40mail.gmail.com%3E. On Tue, 4 Mar 2014 02:40:12 +0100, Samuel Thibault samuel.thiba...@gnu.org wrote: Roland McGrath, le Mon 03 Mar 2014 15:36:52 -0800, a écrit : Roland McGrath, le Fri 20 Dec 2013 13:05:42 -0800, a ,Aicrit : The linker is supposed to define those symbols automagically. Did it break? We have been having $,1r| checking for sufficient default -shared layout... no What does this have to do with anything? It is what makes the Makefile choose between using the empty shlib-lds/shlib-lds-flags or using the explicit shlib.lds file. Are you saying that the linker does not define __start_* and __stop_* symbols automagically when it's given a custom linker script? It seems libc's __start_* and __stop_* symbols get defined automagically indeed. This however doesn't happen for libpthread apparently: /usr/src/eglibc-2.18/build-tree/hurd-i386-libc/libpthread/libpthread_pic.a(pt-initialize.os): In function `__pthread_init': /usr/src/eglibc-2.18/libpthread/./pthread/pt-initialize.c:77: undefined reference to `__stop___pthread_init' /usr/bin/ld.bfd.real: /usr/src/eglibc-2.18/build-tree/hurd-i386-libc/libpthread/libpthread_pic.a(pt-initialize.os): relocation R_386_GOTOFF against undefined hidden symbol `__stop___pthread_init' can not be used when making a shared object Now I'm wondering why for instance __start/stop___libc_atexit are specified. This comes from Ulrich's “Place __libc_subfreeres, __libc_atexit, and __libc_thread_subfreeres sections after .jcr section.”. I don't know what this is really useful for. In my current GCC work, I have just hit what seems to be a similar (the same?) issue: http://news.gmane.org/find-root.php?message_id=%3C87lhvjhl6e.fsf%40kepler.schwinge.homeip.net%3E. Will try to have a look at this next week. Grüße, Thomas pgpJBI_3rfxQA.pgp Description: PGP signature
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 = .);\
two build system issues
Hi :) there are two build system issues that are driving me mad (well, the first one at least). buildbot@pluto:/home/pluto/hurd/build/build-deb$ make -C libdiskfs || echo $? 2 Yes, that's most helpful. Not. buildbot@pluto:/home/pluto/hurd/build/build-deb/libdiskfs$ rm demuxer.d buildbot@pluto:/home/pluto/hurd/build/build-deb/libdiskfs$ make demuxer.o set -e; gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I. -I../../libdiskfs -I.. -I../.. -I../include -I../../include -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -DPACKAGE_NAME=\GNU\ Hurd\ -DPACKAGE_TARNAME=\hurd\ -DPACKAGE_VERSION=\0.5\ -DPACKAGE_STRING=\GNU\ Hurd\ 0.5\ -DPACKAGE_BUGREPORT=\bug-hurd@gnu.org\ -DPACKAGE_URL=\http://www.gnu.org/software/hurd/\; -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1 -DHAVE_USELOCALE=1 -DHAVE_FILE_EXEC_FILE_NAME=1 -DHAVE_EXEC_EXEC_FILE_NAME=1 -DHAVE__HURD_EXEC_FILE_NAME=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PARTED_PARTED_H=1 -DHAVE_LIBPARTED=1 -DHAVE_LIBUUID=1 -DHAVE_LIBDL=1 -DYYTEXT_POINTER=1 -DX11_PREFIX=\/usr\ -DHAVE_DAEMON=1 -DHAVE_BLKID=1 -M -MG ../../libdiskfs/demuxer.c | sed demuxer.d.new -e 's%demuxer\.o:%demuxer.o demuxer_pic.o demuxer_p.o demuxer.d: %' -e 's% [^ ]*/gcc-lib/[^ ]*\.h%%g' mv -f demuxer.d.new demuxer.d buildbot@pluto:/home/pluto/hurd/build/build-deb/libdiskfs$ echo $? 2 Now I take the gcc line and remove -M -MG: buildbot@pluto:/home/pluto/hurd/build/build-deb/libdiskfs$ gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I. -I../../libdiskfs -I.. -I../.. -I../include -I../../include -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -DPACKAGE_NAME=\GNU\ Hurd\ -DPACKAGE_TARNAME=\hurd\ -DPACKAGE_VERSION=\0.5\ -DPACKAGE_STRING=\GNU\ Hurd\ 0.5\ -DPACKAGE_BUGREPORT=\bug-hurd@gnu.org\ -DPACKAGE_URL=\http://www.gnu.org/software/hurd/\; -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1 -DHAVE_USELOCALE=1 -DHAVE_FILE_EXEC_FILE_NAME=1 -DHAVE_EXEC_EXEC_FILE_NAME=1 -DHAVE__HURD_EXEC_FILE_NAME=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PARTED_PARTED_H=1 -DHAVE_LIBPARTED=1 -DHAVE_LIBUUID=1 -DHAVE_LIBDL=1 -DYYTEXT_POINTER=1 -DX11_PREFIX=\/usr\ -DHAVE_DAEMON=1 -DHAVE_BLKID=1 ../../libdiskfs/demuxer.c In file included from ../../libdiskfs/demuxer.c:23:0: ../libports/notify_S.h:12:23: fatal error: mig-decls.h: No such file or directory #include mig-decls.h ^ compilation terminated. This is the first bug. I'd love if someone knew how to fix this. It is easy enough to trigger, just add a non-existing #include to any .c file. The second issue is due to me doing an out-of-tree build. That it currently works is more or less by chance I fear. I just came up with a (legit in my opinion) patch that breaks oot builds. So what happens here is that demuxer.c includes ../libports/notify_S.h, which is a mig-generated file: buildbot@pluto:/home/pluto/hurd/build/build-deb/libdiskfs$ ls ../libports/notify_S.h ../libports/notify_S.h And this file includes mig-decls.h (that's the change I made that breaks the build), because that file is in the source tree: buildbot@pluto:/home/pluto/hurd/build/build-deb/libdiskfs$ ls ../libports/mig-decls.h ls: cannot access ../libports/mig-decls.h: No such file or directory buildbot@pluto:/home/pluto/hurd/build/build-deb/libdiskfs$ ls ../../libports/mig-decls.h ../../libports/mig-decls.h :/ Any help? Justus
Re: [PATCHv2,HURD] Add fork hooks for pthread_atfork
Thomas Schwinge tho...@codesourcery.com skribis: Manolis has hit this issue again, http://news.gmane.org/find-root.php?message_id=%3CCAFtzXzNgS8KEwRJO74SF7zZPMnwFkW_m1qvir6y7-WNwaKEsWQ%40mail.gmail.com%3E. On Tue, 4 Mar 2014 02:40:12 +0100, Samuel Thibault samuel.thiba...@gnu.org wrote: Roland McGrath, le Mon 03 Mar 2014 15:36:52 -0800, a écrit : Roland McGrath, le Fri 20 Dec 2013 13:05:42 -0800, a ,Aicrit : The linker is supposed to define those symbols automagically. Did it break? The mechanism does work on GNU/Linux, for instance with the __libc_subfreeres hook: --8---cut here---start-8--- $ objdump -t libc-2.19.so | grep -E '__(stop|start).*libc_subfreeres' 0039f750 l .dtors __start___libc_subfreeres 0039f840 l __libc_subfreeres __stop___libc_subfreeres --8---cut here---end---8--- Manolis: could you add an #error in libc-symbols.h to make sure the non-empty definition of ‘DEFINE_HOOK’ is getting used? Thanks, Ludo’.
Re: [PATCH] include: make the notify_port_t types translation functions mutable
Justus Winter, le Sat 05 Apr 2014 23:21:24 +0200, a écrit : Make the intran, outtran and destructor functions mutable using preprocessor macros. Make it possible to inject imports using the NOTIFY_IMPORTS macro. This way, userspace servers can provide their own translation functions. Ack * include/mach/notify.defs: Honor NOTIFY_IMPORTS. (notify_port_t): Make the translation mutable using preprocessor macros. --- include/mach/notify.defs | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/include/mach/notify.defs b/include/mach/notify.defs index e06f6b4..fdf35e9 100644 --- a/include/mach/notify.defs +++ b/include/mach/notify.defs @@ -28,6 +28,10 @@ subsystem notify 64; #include mach/std_types.defs +#ifdef NOTIFY_IMPORTS +NOTIFY_IMPORTS +#endif + #if SEQNOS serverprefix do_seqnos_; serverdemux seqnos_notify_server; @@ -37,7 +41,17 @@ serverdemux notify_server; #endif SEQNOS type notify_port_t = MACH_MSG_TYPE_MOVE_SEND_ONCE - ctype: mach_port_t; + ctype: mach_port_t +#ifdef NOTIFY_INTRAN + intran: NOTIFY_INTRAN +#endif +#ifdef NOTIFY_OUTTRAN + outtran: NOTIFY_OUTTRAN +#endif +#ifdef NOTIFY_DESTRUCTOR + destructor: NOTIFY_DESTRUCTOR +#endif +; /* MACH_NOTIFY_FIRST: 0100 */ skip; -- 1.9.1 -- Samuel P moo N moo ? D P: keski t'arrive? :)) P m N moo ? P rien le net marche je suis content :) -+- #ens-mim - accro du net -+-
Re: [PATCH 2/3] exec: fix receiver lookup
Justus Winter, le Sat 05 Apr 2014 00:07:15 +0200, a écrit : * exec/Makefile (exec_startup-MIGSFLAGS): New variable. * exec/execmutations.h: Add mutators for exec_startup_t. * exec/mig-decls.h: New file. * exec/priv.h (bootinfo_t): New type declaration to appease mig. * exec/exec.c (S_exec_startup_get_info): Fix receiver lookup. Ack.
Re: [PATCH 3/3] libdiskfs: fix receiver lookup
Justus Winter, le Sat 05 Apr 2014 00:07:16 +0200, a écrit : * libdiskfs/Makefile (exec_startup-MIGSFLAGS): New variable. * libdiskfs/diskfs.h (struct bootinfo): New struct declaration. (diskfs_begin_using_bootinfo_port): New function. (diskfs_end_using_bootinfo): Likewise. * libdiskfs/fsmutations.h: Add mutators for exec_startup_t. * libdiskfs/priv.h (bootinfo_t): New type declaration to appease mig. * libdiskfs/boot-start.c (S_exec_startup_get_info): Fix receiver lookup. Ack.
Re: [PATCH 1/3] hurd: add a new type for the exec_startup protocol
Justus Winter, le Sat 05 Apr 2014 00:07:14 +0200, a écrit : * hurd/hurd_types.defs (exec_startup_t): New type. * hurd/hurd_types.h (exec_startup_t): Likewise. * hurd/exec_startup.defs: Honor EXEC_STARTUP_IMPORTS. (exec_startup_get_info): Use the new type as receiver. Ack.
Re: two build system issues
Justus Winter, le Sat 05 Apr 2014 20:16:12 +0200, a écrit : buildbot@pluto:/home/pluto/hurd/build/build-deb$ make -C libdiskfs || echo $? 2 Yes, that's most helpful. Not. I've seen that too. It happens when the dep files have a non-existing entry. I usually use make -d to see what is missing. Samuel
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
