Re: Trig Function Linking Problems

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

AJAskey <AskeyAJ@gmail.com> writes:

> On Apr 17, 6:55 am, Markus E Leypold
> <development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> wrote:
>
>> There are switches to see how (paths and all) the c compiler is called
>> behind the scenes. There are switches that can be passed through to
>> gcc which make gcc show how it calls the linker and various processing
>> stages. Try them.
>>
>> Try nm and ldd on finished binaires and intermediate object files to
>> see linkage, exports and definitions.
>>
>> If your theory about libm not getting linked right is true, then you
>> should see something unusual.
>>
>> BTW: Your new target is a RH 7. I seem to remember that they were
>> still in the process of switching libc and had an experimental egcs
>> compiler. So something messed up in linking, calling the right
>> compiler stages, assembler or dynmic linking is probably a good first
>> gues.
>>
>> Regards -- Markus
>
> Markus - Thanks for the nm and ldd suggestions.  I was looking for
> something like that.  I've tried all the gnatmake, gnatbind, and
> gnatlink switches over the past day without much luck.  They told me
> useful stuff, but nm and ldd is what I really need.  I've also tried
> directly linking to the libraries instead of the -lm -lc -lg2c
> switches in the link.  This "changes" something as the output is
> different, but it still doesn't work.

And if you suspect a linking error, don't forget to pass (via gnatmake
or gnatlink) the switch '-v' to gcc. This should tell you exactly what
is happening during linking, like this:

   /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m
   elf_i386 -dynamic-linker /lib/ld-linux.so.2
   /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crt1.o
   /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o
   /usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o
   -L/usr/lib/gcc-lib/i486-linux/3.3.5
   -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. /tmp/ccozkgKd.o -lgcc
   --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
   --no-as-needed /usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o
   /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o

A wrong component linked in should stick out like a sore thumb :-).

> I think this version of Red Hat has the libraries messed up.  The

Quite probably. Or if it plays any ld.so games (for binary
compatibility) it just dynamically pulls in the wrong library.

> errors occur on two totally independent systems. I was working with
> someone last year who had similar problems so that makes three
> independent systems.  This Red Hat bundle is old and it may have been
> fixed.  

But you Ada compiler seems to be newer -- is that possible? Did you
build it yourself and it's perhaps somehow confusing itself with the
system cc?

> Or maybe it was fixed in a subsequent version.  The right answer is
> to upgrade, but that is not an immediate option.  If I can't find
> anything with nm and ldd, I think I will write my own interface to a
> "c" program that does the trig functions as the "c" calls work well.
> I will provide any solution I find back to this thread.


Sounds bad. If upgrading is not an option, producing unreliable
binaries is an option? What I mean, is, that if there is a problem
with libm somewhere, the problems are perhaps also elsewhere, only not
this visible.

Regards -- Markus