Sorry Frank, here is the complete report: I link a rather large application (500+ Pascal files with 20 C files) into one executable. I precompile everything as objects and then perform the following commands to link: find /src -name '*.o' -exec echo -n {} " " ; > lnk.tmp echo -n /src/os/os.a " " >> lnk.tmp\ touch rds.map gcc -static `cat lnk.tmp` -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker -Map rds.map
The os.a is just a library I create from all the precompiled C stuff. I do not think any of this is a big deal, as I have done this successfully in the past, before the system had to be upgraded. My library paths should be fine (/lib /usr/lib/ /usr/local/lib /usr/C11R6/lib /usr/local/fpc/lib). Nothing unusual, and /usr/lib is where all the gcc/gpc libraries live.
Using '-v' does not give much more info other than showing all the objects I am linking together.
However, I can compile small test programs of 1 file or slightly more successfully using GPC on the command line (--automake). They will run with no problems.
Someone needs to write these companies like Mandrake, Redhat, Suse and get them to stop using these bad compilers. People have been complaining about this 'v2.96' compiler for 2 years now and they are still distributing them. It's a real pain and trying procedure to get that compiler off and still have their stock programs run correctly (because of library dependencies).
Thanks guys! Adam
-----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Thursday, October 18, 2001 7:20 PM To: gpc@gnu.de Subject: Re: installation problems
Oldham, Adam wrote:
I am using Mandrake Linux with kernel 2.4.8. It had the wonderful version of gcc 2.96 installed on it stock. I've since downgraded to gcc 2.95.3. I've downloaded gpc-20010924, and installed it the regular old way I've installed all the other version of GPC I've gotten the past 2 years. It installs fine, into /usr just like gcc.
I can compile files with no problem as well. I compile all my pascal
files
to only create object files, no other parameters from the command line. When linking all these objects together statically, I get a few errors
like
this: /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o): In function `_p_Real_Sin': /v/oldham/gcc-2.95.3/gcc/p/rts/rts.c:642: undefined reference to `sin'
I get the same thing for the functions cos, log, pow, sinl, cosl, logl, expl, powl, sinh, cosh. I've researched this some, and linking the -lm (math library) while performing my link does not help this. Can anyone
help
at all with this in particular?
How you do link? Do you call gpc, gcc, or ld directly? What command line? Does it work if you just compile and link with GPC (--automake)? Does the linker command line you see with `-v' help you? ...
I think I mentioned once or twice in the past few days that I'd prefer complete reports ... :-(
Should GPC have linked -lm while it was building?
No, it's not the gpc executable, but your program executable that needs -lm.
Marco van de Voort wrote:
Should GPC have linked -lm while it was building? And if so, can
someone
help me find where that is. I've been looking at this for hours now.
Sounds like not linked with libgcc, or wrong (out of sync) version.
No, libm is quite independent of libgcc.
Frank