[openbeosnetteam] Re: libnet fix

>Daniel Reinhold wrote:
>
>> point of view, trying to actively develop a lib with the SAME NAME 
and 
>> the EXACT SAME SET OF EXPORTED SYMBOLS as a standard existing lib 
(and 
>> being loaded from the same set of standard search paths) is just 
asking 
>> for brain frying troubles.
>
>Oh well, it isn't really a problem if you know where to put the 
library.
>
>Assuming you want to execute /boot/foobar/testapp, and this app 
>needs libnet.so the BeOS loader will search the library in this order:
>
>1. /boot/foobar/lib/libnet.so
>2. /boot/home/config/lib/libnet.so
>3. /boot/beos/system/lib/libnet.so

Yes, the search rules for loading libs is pretty straightforward. But 
it's beside the point (well, at least the point I was trying to make). 
We all make silly errors from time to time, usually because we're 
concentrating on some complex detail and overlook the simple stuff.  
Why not set up the environment, whenever possible, so that errors jump 
out right in your face, rather than being obscured? That's the purpose 
of using a unique name for a lib in development.


>
>using the same library name works very well for media kit
>testing, where I just place a link to our media kit library in the 
distro dir
>into /boot/home/config/lib/
>
>> Why not use 'libobosnet.so'? Or something distinctive. You can *
always*
>You can't run normal R5 programs.

Well, yes. But that's not the first priority. The first priority is to 
get the net stack working, tested, robust...


>
>> change it to the standard name later, once the thing has matured, 
and 
>> test against that. In the mean time, sanity is preserved. Is this 
>You can do that, if you need it. but the need to do it is very low.
>
>However, this linker bug(?) should be investigated. it is really crazy 
that 
>we can't link a library from object files that has a symbol called 
_res.

Yes a true bug in the linker would be a serious issue. However, the 
chance that the source of the problem is located somewhere in our setup 
is FAR HIGHER, IMO.

>
>> absolutely necessary? No. But isn't it worth keeping things straight 
>> and not spending hours (days) tracking down non-existent problems 
>> because of linking against the wrong lib?
>We are not linking against the wrong lib.

Really? Sure looks like that's the problem. Maybe not.


>
>Whenever the name "libnet.so" (or "libmedia.so") is used in the 
jamfile,
>we will link against our new library, while using the name "net" or 
"media"
>will link to the R5 files.
>
>The jamfiles for route, ping, etc. are correct and link against the 
new file.
>
>> Just a kooky suggestion.
>Yes, we (you) can rename to libobosnet.so', but I don't believe that 
this is very
>useful workaround to solve this bug (renaming _res is only a 
workaround, too)

Ok, well, it wasn't really meant as a workaround for the bug. By all 
means track down this particular problem and fix it. Certainly now that 
it has reared its ugly head, it must be dealt with -- I would never 
suggest ignoring any problem.

My advice is more general, about dealing with one thing at a time, not 
juggling too many balls at once. Yes, integration with R5 is a 
necessary step, but it needn't be done in one shot, while the net stack 
is still being developed. It could be done in steps, where first, the 
stack is heavily tested, debugged, refined, etc. until it seems to be 
in really good shape, THEN test it as a replacement component with R5 
apps later.

A unique name for the lib keeps you from having to deal with R5 
integration/conflict issues up front. They can be dealt with later (and 
presumably with more confidence). It's just the standard old principle 
of "don't call two different things by the same" (If you have two sons, 
don't name them both Larry).

Anyway, that's my suggestion, FWIW. I realize that I'm sticking my nose 
in here, so I guess I should but out, not being part of the net team. 
You guys can work it out however you think is best. If you ignore my 
advice and make a kick-ass net stack anyway, then I guess I'll be the 
foolish one!

>
>Marcus
>
>

Other related posts: