From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1e11857ea4f39dd6 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Trig Function Linking Problems References: <1176755562.190964.167640@w1g2000hsg.googlegroups.com> <20ejmjj3ci.fsf@hod.lan.m-e-leypold.de> <1176803966.623937.251290@e65g2000hsc.googlegroups.com> From: Markus E Leypold Organization: N/A Date: Tue, 17 Apr 2007 12:55:21 +0200 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:+MdFk2kf9Rn+JLaePYNXwV+vmvQ= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.220.162 X-Trace: news.arcor-ip.de 1176806865 88.72.220.162 (17 Apr 2007 12:47:45 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.google.com!news.germany.com!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:15082 Date: 2007-04-17T12:55:21+02:00 List-Id: AJAskey 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