[openbeosnetteam] Re: Fix for resolving host names

"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].

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?)

Andrew

Other related posts: