[lug] Compiling strangeness

[D. Stimits]

"Keith C. Herold" wrote:
> 
> Howdy! I have an RH 7.1 machine that I using to work on a network
> assingment.  The professor supplied a library that drops packets randomly,
> but when I linked against it, no packets were dropped at all (with correct
> arguments, etc.).  Later, I was using sendto and recvfrom to handle some UDP
> packets (same homework), into separate, statically declared structs (which
> had only statically declared members), and they were being overwritten by
> each other.  I switched machines to another 7.1 box, and the same problems
> occurred.  I switched to yet another machine (7.1), and everything worked
> correctly.
> 
> All three machines are using the same build of GCC (2.96 20000731).
> 
> I am now concerned.  The problem is that I need gcc to build gcc, and I
> don't know how to check whether it's the libraries, gcc, the linker or
> whatever that is causing the problems, and I need my machine to work
> correctly for other, more important projects.  Any suggestions?

Use ldd on the compiled program in question, see if it really is linked
against your library. Use ltrace to see what library calls are made
while using the program (you might find the "tee" program useful to help
log things, simply pipe output to tee and let tee name a log, so it both
displays and logs at the same time). If it turns out that this library
intercepts system calls by providing its own version, you can use strace
in a similar way. To see what symbols are in the library, you can run nm
on the library itself (perhaps not useful if it is stripped). In the
case of substitute functions that have the same name as the real ones,
linking order matters: the linker will use the first version it finds in
its search path that matches the requirements.

The libraries I know of which simulate poor networking are all kernel
modules or kernel patches, I do not know of any libraries in the
traditional sense. I believe those versions I am aware of have special
setup to name an interface before they actually engage the poor
condition simulation. You may just need to jump through some more hoops
before it is activated.

D. Stimits, stimits at idcomm.com

> 
> --Keith
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug