Trig Function Linking Problems

Trig Function Linking Problems

[AJAskey]

Hi.  We are moving some software from and ancient workstation to a
newer one.  The environment is still several years old but newer than
the old-timer we are leaving.  We cannot get the TRIG functions to
work as there appears to be a problem interfacing to the library.  The
following test code works on the old-time system, but fails on two
separate newer systems.  Any help would be greatly appreciated.

with ada.text_io;
  use ada.text_io;
with ada.numerics.elementary_functions;
procedure TRIG is
  a,b,c,d : float;
begin
  a := 3.1415/4.0;
  b := ada.numerics.elementary_functions.sin(x=>a);
  c := ada.numerics.elementary_functions.cos(x=>a);
  d := ada.numerics.elementary_functions.tan(x=>a);
  put_line("sin(a)" & float'image(b));
  put_line("cos(a)" & float'image(c));
  put_line("tan(a)" & float'image(d));
  put_line("a     " & float'image(a));
end TRIG;

>From system with  : GNATMAKE 3.13p  (20000509) Copyright 1995-2000
Free Software Foundation, Inc.
gcc 2.96
Linux Red Hat 7.1 2.96-98


[I don't need to do anything special except a gnatmake.]

>>gnatmake trig
gnatgcc -c trig.adb
gnatbind -x trig.ali
gnatlink trig.ali

>>trig
sin(a) 7.07090E-01
cos(a) 7.07123E-01
tan(a) 9.99954E-01
a      7.85375E-01

---------------------------------------------

>From new system with : GNATMAKE 3.2.3-13  (20030502) Copyright
1995-2000 Free Software Foundation, Inc.
gcc 3.2.3
Linux Red Hat 3.2.3-53

>>gnatmake trig
gcc -c trig.adb
gnatbind -x trig.ali
gnatlink trig.ali

>>trig

raised CONSTRAINT_ERROR : s-imgrea.adb:236


[I tried linking in the -lm library which is required in the "c"
version of this test.  I also tried linking a few others, but
continued to get the run-time error.

On another similar system, the program ran but returned NaN in the
debugger for b,c,d after the sin,cos,tan calls.  I assume it really
isn't finding the library.]

>>gnatmake -c trig.adb
>>gnatbind -x trig
>>gnatlink -lm -lc -lgnat trig

>>trig

raised CONSTRAINT_ERROR : s-imgrea.adb:236


Any ideas what I should be linking in?

Thanks much.
Andy

Re: Trig Function Linking Problems

[Jeffrey Creem]

AJAskey wrote:
> Hi.  We are moving some software from and ancient workstation to a
> newer one.  The environment is still several years old but newer than
> the old-timer we are leaving.  We cannot get the TRIG functions to
> work as there appears to be a problem interfacing to the library.  The
> following test code works on the old-time system, but fails on two
> separate newer systems.  Any help would be greatly appreciated.
> 
> with ada.text_io;
>   use ada.text_io;
> with ada.numerics.elementary_functions;
> procedure TRIG is
>   a,b,c,d : float;
> begin
>   a := 3.1415/4.0;
>   b := ada.numerics.elementary_functions.sin(x=>a);
>   c := ada.numerics.elementary_functions.cos(x=>a);
>   d := ada.numerics.elementary_functions.tan(x=>a);
>   put_line("sin(a)" & float'image(b));
>   put_line("cos(a)" & float'image(c));
>   put_line("tan(a)" & float'image(d));
>   put_line("a     " & float'image(a));
> end TRIG;
> 
>>From system with  : GNATMAKE 3.13p  (20000509) Copyright 1995-2000
> Free Software Foundation, Inc.
> gcc 2.96
> Linux Red Hat 7.1 2.96-98
> 
> 
> [I don't need to do anything special except a gnatmake.]
> 
>>> gnatmake trig
> gnatgcc -c trig.adb
> gnatbind -x trig.ali
> gnatlink trig.ali
> 
>>> trig
> sin(a) 7.07090E-01
> cos(a) 7.07123E-01
> tan(a) 9.99954E-01
> a      7.85375E-01
> 
> ---------------------------------------------
> 
>>From new system with : GNATMAKE 3.2.3-13  (20030502) Copyright
> 1995-2000 Free Software Foundation, Inc.
> gcc 3.2.3
> Linux Red Hat 3.2.3-53
> 
>>> gnatmake trig
> gcc -c trig.adb
> gnatbind -x trig.ali
> gnatlink trig.ali
> 
>>> trig
> 
> raised CONSTRAINT_ERROR : s-imgrea.adb:236
> 
> 
> [I tried linking in the -lm library which is required in the "c"
> version of this test.  I also tried linking a few others, but
> continued to get the run-time error.
> 
> On another similar system, the program ran but returned NaN in the
> debugger for b,c,d after the sin,cos,tan calls.  I assume it really
> isn't finding the library.]
> 
>>> gnatmake -c trig.adb
>>> gnatbind -x trig
>>> gnatlink -lm -lc -lgnat trig
> 
>>> trig
> 
> raised CONSTRAINT_ERROR : s-imgrea.adb:236
> 
> 
> Any ideas what I should be linking in?
> 
> Thanks much.
> Andy
> 

I don't think the problem is not finding the library as this generally 
gives a much more specific error. I would guess it is more fundamentally 
broken than just a library issue.

Can you update to a GNATPro version or a later GCC version?

Re: Trig Function Linking Problems

[Markus E Leypold]

Jeffrey Creem <jeff@thecreems.com> writes:

> AJAskey wrote:
>> Hi.  We are moving some software from and ancient workstation to a
>> newer one.  The environment is still several years old but newer than
>> the old-timer we are leaving.  We cannot get the TRIG functions to
>> work as there appears to be a problem interfacing to the library.  The
>> following test code works on the old-time system, but fails on two
>> separate newer systems.  Any help would be greatly appreciated.
>> with ada.text_io;
>>   use ada.text_io;
>> with ada.numerics.elementary_functions;
>> procedure TRIG is
>>   a,b,c,d : float;
>> begin
>>   a := 3.1415/4.0;
>>   b := ada.numerics.elementary_functions.sin(x=>a);
>>   c := ada.numerics.elementary_functions.cos(x=>a);
>>   d := ada.numerics.elementary_functions.tan(x=>a);
>>   put_line("sin(a)" & float'image(b));
>>   put_line("cos(a)" & float'image(c));
>>   put_line("tan(a)" & float'image(d));
>>   put_line("a     " & float'image(a));
>> end TRIG;
>>
>>>From system with  : GNATMAKE 3.13p  (20000509) Copyright 1995-2000
>> Free Software Foundation, Inc.
>> gcc 2.96
>> Linux Red Hat 7.1 2.96-98
>> [I don't need to do anything special except a gnatmake.]
>>
>>>> gnatmake trig
>> gnatgcc -c trig.adb
>> gnatbind -x trig.ali
>> gnatlink trig.ali
>>
>>>> trig
>> sin(a) 7.07090E-01
>> cos(a) 7.07123E-01
>> tan(a) 9.99954E-01
>> a      7.85375E-01
>> ---------------------------------------------
>>
>>>From new system with : GNATMAKE 3.2.3-13  (20030502) Copyright
>> 1995-2000 Free Software Foundation, Inc.
>> gcc 3.2.3
>> Linux Red Hat 3.2.3-53
>>
>>>> gnatmake trig
>> gcc -c trig.adb
>> gnatbind -x trig.ali
>> gnatlink trig.ali
>>
>>>> trig
>> raised CONSTRAINT_ERROR : s-imgrea.adb:236
>> [I tried linking in the -lm library which is required in the "c"
>> version of this test.  I also tried linking a few others, but
>> continued to get the run-time error.
>> On another similar system, the program ran but returned NaN in the
>> debugger for b,c,d after the sin,cos,tan calls.  I assume it really
>> isn't finding the library.]
>>
>>>> gnatmake -c trig.adb
>>>> gnatbind -x trig
>>>> gnatlink -lm -lc -lgnat trig
>>
>>>> trig
>> raised CONSTRAINT_ERROR : s-imgrea.adb:236
>> Any ideas what I should be linking in?
>> Thanks much.
>> Andy
>>
>
> I don't think the problem is not finding the library as this generally
> gives a much more specific error. I would guess it is more
> fundamentally broken than just a library issue.
>
> Can you update to a GNATPro version or a later GCC version?


It seems to be some strange hardware (compatibility?) problem. The
file in question has the following comment:


            --  The following exception is only raised in case of erroneous
            --  execution, where a number was considered valid but still
            --  fails to scale up. One situation where this can happen is
            --  when a system which is supposed to be IEEE-compliant, but
            --  has been reconfigured to flush denormals to zero.

            if Scale < -Maxscaling then
               raise Constraint_Error;
            end if;

I admit I don't know completely what the means, but suggest to have a
look into the library and work from there.

Regards -- Markus

Re: Trig Function Linking Problems

[Jeffrey R. Carter]

AJAskey wrote:
> 
> with ada.text_io;
>   use ada.text_io;
> with ada.numerics.elementary_functions;
> procedure TRIG is
>   a,b,c,d : float;
> begin
>   a := 3.1415/4.0;
>   b := ada.numerics.elementary_functions.sin(x=>a);
>   c := ada.numerics.elementary_functions.cos(x=>a);
>   d := ada.numerics.elementary_functions.tan(x=>a);
>   put_line("sin(a)" & float'image(b));
>   put_line("cos(a)" & float'image(c));
>   put_line("tan(a)" & float'image(d));
>   put_line("a     " & float'image(a));
> end TRIG;

>>From new system with : GNATMAKE 3.2.3-13  (20030502) Copyright
> 1995-2000 Free Software Foundation, Inc.
> gcc 3.2.3
> Linux Red Hat 3.2.3-53
> 
>>> gnatmake trig
> gcc -c trig.adb
> gnatbind -x trig.ali
> gnatlink trig.ali
> 
>>> trig
> 
> raised CONSTRAINT_ERROR : s-imgrea.adb:236

s-imgrea.adb is package System.Img_Real, used to implement Float'Image. 
Maybe it's a compiler error, or maybe there's something wrong with the 
values you're getting. What happens if you use Ada.Text_IO.Float_IO? You 
should also be able to find a newer version of the compiler and try it.

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: Trig Function Linking Problems

[AJAskey]

Thanks for the responses.  I really think the pragma "c" call to the
actual Linux math library is not working.  I've had this same problem
many times over the years.  In "c", many times I would not get an
error message at link time if it could not find the correct library
with the sin(), cos(), etc calls.  The "c" function would "appear" to
work (step into somewhere in the debugger) but garbage was always
returned.  This appears to be what is happening.  Ada knows it is a
valid call and doesn't complain.  But somewhere in the depths of the
call nothing actually happens.

If I set b=1.0 then make the call b:=sin(a), b is changed to NaN.
Something is happening but definitely not the sine function.

If I had written the call then I would assume the code was wrong.  But
I am using code from the GNAT Ada library that works fine on a
different computer.  I'm pretty sure it has something to do with the
gnatlink activity.  Either something is defaulting correctly on the
working system that is not the default on the newer system, or it just
cannot find the library.  I tested the same simple algorithm in "c"
and it works fine - which means the library is available on the
system.

If anyone has any other ideas please let me know as this is a show
stopper.

Thanks.
Andy

Re: Trig Function Linking Problems

[Markus E Leypold]

AJAskey <AskeyAJ@gmail.com> writes:

> Thanks for the responses.  I really think the pragma "c" call to the
> actual Linux math library is not working.  I've had this same problem
> many times over the years.  In "c", many times I would not get an
> error message at link time if it could not find the correct library
> with the sin(), cos(), etc calls.  The "c" function would "appear" to
> work (step into somewhere in the debugger) but garbage was always
> returned.  This appears to be what is happening.  Ada knows it is a
> valid call and doesn't complain.  But somewhere in the depths of the
> call nothing actually happens.
>
> If I set b=1.0 then make the call b:=sin(a), b is changed to NaN.
> Something is happening but definitely not the sine function.
>
> If I had written the call then I would assume the code was wrong.  But
> I am using code from the GNAT Ada library that works fine on a
> different computer.  I'm pretty sure it has something to do with the
> gnatlink activity.  Either something is defaulting correctly on the
> working system that is not the default on the newer system, or it just
> cannot find the library.  I tested the same simple algorithm in "c"
> and it works fine - which means the library is available on the
> system.
>
> If anyone has any other ideas please let me know as this is a show
> stopper.

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

Re: Trig Function Linking Problems

[AJAskey]

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.

I think this version of Red Hat has the libraries messed up.  The
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.  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.

Thanks.
Andy

Re: Trig Function Linking Problems

[Markus E Leypold]

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

Re: Trig Function Linking Problems

[Ludovic Brenta]

AJAskey wrote:
> If anyone has any other ideas please let me know as this is a show
> stopper.

Here are a few ideas for investigation:

Compare the output of "ldd" on the executable file on the old
workstation and on the new ones.

Copy the working executable (along with libgnat-3.13.so and
libgnarl-3.13p.so if applicable) to the new workstations; try to run
it there.

What is the processor architecture of each workstation?

What happens if you compile and link with GNAT 3.15p? (see [1] if you
don't know where to get it).

Finally: Ada support in GCC 3.2 was *not* production-worthy as
explained on [2].

[1] http://en.wikibooks.org/wiki/Ada_Programming/Installing#GNAT_3.15p
[2] http://en.wikibooks.org/wiki/Ada_Programming/Installing#GCC

HTH

--
Ludovic Brenta.

Re: Trig Function Linking Problems

[Dirk Heinrichs]

AJAskey wrote:

>>From system with  : GNATMAKE 3.13p  (20000509) Copyright 1995-2000
> Free Software Foundation, Inc.
> gcc 2.96
> Linux Red Hat 7.1 2.96-98
>>>trig
> sin(a) 7.07090E-01
> cos(a) 7.07123E-01
> tan(a) 9.99954E-01
> a      7.85375E-01

Don't know if that helps, but I got a correct result on my Gentoo Linux with
gnat-gcc 4.1.2:

heini@gondolin ~ % gnatmake trig
gnatgcc -c trig.adb
gnatbind -x trig.ali
gnatlink trig.ali
heini@gondolin ~ % ./trig
sin(a) 7.07090E-01
cos(a) 7.07123E-01
tan(a) 9.99954E-01
a      7.85375E-01
heini@gondolin ~ % gnatgcc --version
gnatgcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.

So I'd guess it's like someone wrote before, you may have an
incompatible/broken egcs/gcc/gnat mix.

Bye...

        Dirk

Re: Trig Function Linking Problems

[AJAskey]

Thanks again for the responses.  I will give the suggestions a try.

I did get the trig functions to work on one newer system.  The ldd -v
trig command showed that libgnat was not being linked - for some
reason.  I changed my build command to:

gnatmake -v trig.adb -largs -lm -lc /usr/lib/libgnat-3.4.so.1

and it worked.  I'm not sure why a simple gnatmake didn't link in the
libgnat library.  It did on the older system and this led me to try to
explicitly link it.

On the other system (the one I really need it to work on) it didn't
work.  One reason may be that the libgnat-3.4.so.1 was not there - but
the libgnat-3.15a.so.1 file was.  This is interesting as they appear
to be built from the same CD.  I will try to get  the newer libgnat
file onto that system.  Currently, they are not on the same network.

Thanks.
Andy

Re: Trig Function Linking Problems

[Ludovic Brenta]

AJAskey <AskeyAJ@gmail.com> writes:
> Thanks again for the responses.  I will give the suggestions a try.
>
> I did get the trig functions to work on one newer system.  The ldd -v
> trig command showed that libgnat was not being linked - for some
> reason.  I changed my build command to:
>
> gnatmake -v trig.adb -largs -lm -lc /usr/lib/libgnat-3.4.so.1
>
> and it worked.  I'm not sure why a simple gnatmake didn't link in the
> libgnat library.  It did on the older system and this led me to try to
> explicitly link it.
>
> On the other system (the one I really need it to work on) it didn't
> work.  One reason may be that the libgnat-3.4.so.1 was not there - but
> the libgnat-3.15a.so.1 file was.  This is interesting as they appear
> to be built from the same CD.  I will try to get  the newer libgnat
> file onto that system.  Currently, they are not on the same network.

Ah yes - this is consistent with [1] and confirms that the Ada in GCC
3.2 is more or less broken.  What version of GNAT does the newer
system have?

[1] http://www.ada-france.org/debian/debian-ada-policy.html#A-note-about-GNAT_0027s-shared-libraries

-- 
Ludovic Brenta.