On Fri, Sep 11, 2009 at 14:47:45 +1000, Geoff Wing wrote: > On Thursday 2009-09-10 13:55 +0300, Antti Kantee output: > :No, that is *absolutely the wrong thing*, since while it might make > :the build work, it breaks the resulting binary. I'm a bit baffled that > :breakage like that was committed to rump_nfs/Makefile in the first place. > : > :It seems there is a regression in binutils 2.19 which prevents the > :standard DOMAIN_DEFINE() macro from working. I suggest reverting back > :to 2.16 until the cause is identified and the bug is fixed. > > No, that's a red herring. The problem is a long-standing one with > sys/kern/uipc_domain.c (from rev 1.49 2005/01/23 onwards). > > Someone has it use link sets without ever creating a section header so > that they actually work properly. This caused librumpnet.so to also > have a bad copy.
No, uipc_domain.c does not need to create the link set section because other files in the kernel do. In rump world things get more tricky because uipc_domain.c and files that actually define domains live in different DSOs. So uipc_domain.o has unresolved refs to start/stop symbols, which is ok. The real problem, as pooka explained further down the thread, is that the start/stop symbols were no longer generated in the component that actually defined domains because no file in that component actually referenced them (uipc_domain.o is in another DSO) and new binutils changed the way those symbols are created. PS: It's really amazing how rump can cope with link sets in the DSO world at all. One can condescentingly call it a hack, but link sets are not rump's fault. People are most welcome to fix this ugliness properly by helping to get rid of link sets in the kernel. SY, Uwe -- u...@stderr.spb.ru | Zu Grunde kommen http://snark.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
