[openbeosnetteam] Re: Fix for resolving host names
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Tue, 3 Feb 2004 14:04:24 +0100 (MET)
On Mon, 2 Feb 2004, Andrew Bachmann wrote:
> "Philippe Houdoin" <philippe.houdoin@xxxxxxx> wrote:
> >
> > That's a workaround, as h_errno *should* works.
> > netdb.h define is as a macro:
> > #define h_errno (*(_h_errnop()))
> >
> > Something is wrong about our h_errno TLS code, I guess.
> > Will look into it (src/kits/network/libnet/compat.c and headers/posix/
> > netdb.h)...
> >
> > - Philippe
>
> OIC! It's a TLS issue. Since the posix spec doesn't require that h_errno
> is thread-safe, I didn't expect a TLS issue here. TLS is one of the great
> undocumented zones in BeOS IMHO. Since I "speak" TLS, I took a look
> at compat.c. It appears corrrect to me and I ran some tests successfully
> with similar code taken out and put into it's own executable. I also put
> the h_errno implementation into a shared lib (all by itself!) and linked
> to that. I verified that initialize_before was called as it ought to be, and
> the behavior was appropriate. No crash. So I tried linking my tiny
> test program to our libnet.so. ( renamed it libnut.so ) That worked just
> fine too. I stuck "extern int h_errno;" into my test file and that still
> did not break it. Finally I was able to reproduce the problem.
>
> Here's the short of it. If libnet.so is compiled as follows:
>
> gcc -g -nostdlib -nostart -Xlinker -soname="libnet.so" -o
> "../../../../distro/x86.R1/beos/system/lib/
> libnet.so" ..... -lroot
>
> Then the problem occurs. If it is compiled as follows:
>
> gcc -g -nostart -Xlinker -soname="libnet.so" -o
> "../../../../distro/x86.R1/beos/system/lib/libnet.so" .... -
> lroot
>
> Then the problem doesn't occur. More background:
>
> -nostdlib
> Don't use [1] the standard system libraries and [2] startup files when
> linking.
> Only the files you specify will be passed to the linker.
>
> [1] & [2] added by me. We want [2] but not [1].
For the time being -- i.e. until we migrate to our own kernel) -- we
theoretically want both, and thereafter neither. Only theoretically, since
unfortunately libnet.so is a system library on BeOS, which is, er, a bit
problematical when trying to build a replacement for it.
> Well, turns out there is no way to specifiy [2] but not [1]. At least, I
> haven't
> found a direct way to specify it. However! We do have a solution. We know
> which files are in the "startup files". These are specified in your friendly
> "specs" file for gcc:
>
> *startfile:
> crti.o%s crtbegin.o%s %{!nostart:start_dyn.o%s} init_term_dyn.o%s
> %{p:i386-mcount.o%s}
>
> More than you ever wanted to know about gcc I'm sure, but the solution
> lies within. If we link in crti.o to libnet.so as such:
>
> gcc -g -nostdlib -nostart -Xlinker -soname="libnet.so" -o
> "../../../../distro/x86.R1/beos/system/lib/
> libnet.so" ..... /boot/develop/lib/x86/crti.o -lroot
>
> Then it works. Well, almost anyway. Now the initialize_before is getting
> called, but it crashes
> before main. Turns out we need more of those magic .o's. This is a
> completely working solution:
>
> gcc -g -nostdlib -nostart -Xlinker -soname="libnet.so" -o
> "../../../../distro/x86.R1/beos/system/lib/
> libnet.so" /boot/develop/lib/x86/crti.o
> /boot/develop/tools/gnupro-000224/lib/gcc-lib/i586-beos/2.9-
> beos-000224/crtbegin.o
> /boot/develop/obos/current/objects/x86.R1/kernel/glue/init_term_dyn.o
> ........... /boot/develop/lib/x86/crtn.o
> /boot/develop/tools/gnupro-000224/lib/gcc-lib/i586-beos/2.9-beos-
> 000224/crtend.o -lroot
>
> I suspected the solution was not minimal, so I removed crtbegin.o and
> crtend.o. This was
> successful as well. So, I removed init_term_dyn.o. Leaving this: (also
> working)
>
> gcc -g -nostdlib -nostart -Xlinker -soname="libnet.so" -o
> "../../../../distro/x86.R1/beos/system/lib/
> libnet.so" /boot/develop/lib/x86/crti.o ...........
> /boot/develop/lib/x86/crtn.o -lroot
>
> Anyway, so I got curious about these magic files. So I went looking.
>
> http://www.acm.uiuc.edu/bug/Be%20Book/Release_Notes/R4RN_BeIDE.html
> http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00337.html
>
> Y si tu hablas español:
>
> http://www.macprogramadores.org/beos/tutoriales/THD/herramientasgnu/gcc/gcc.html
>
> Those pages say that for a shared lib you have to include: crti.o crtbegin.o
> <your files here>
> crtend.o crtn.o [order matters!!]
>
> Also, it seems for an executable you must include this: start_dyn.o
> /boot/develop/lib/x86/
> init_term_dyn.o /boot/develop/lib/x86/glue-noinit.a [unknown order
> sensitivity]
>
> Presumably at this point someone more knowledgable about the particulars here
> will speak up
> and tell us all what we should do. (namely, include the minimal set that
> works? or include the
> recommended set?) Also we should address this issue for _all_ obos libs,
> since we use -nostdlib
> quite extensively. (I think?)
I believe -nostdlib is only used for libnet.so due to the clash with BeOS'
libnet.so. For all other libraries there shouldn't be a problem. So, for
the time being I'd say, let's do as you suggest, i.e. use -nostdlib for
libnet.so and link manually against the glueing code and libroot.
CU, Ingo
- Follow-Ups:
- [openbeosnetteam] Re: Fix for resolving host names
- From: Philippe Houdoin
- References:
- [openbeosnetteam] Re: Fix for resolving host names
- From: Andrew Bachmann
Other related posts:
- » [openbeosnetteam] Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- » [openbeosnetteam] Re: Fix for resolving host names
- [openbeosnetteam] Re: Fix for resolving host names
- From: Philippe Houdoin
- [openbeosnetteam] Re: Fix for resolving host names
- From: Andrew Bachmann