Juanjo wrote:
>
> On Sep 8, 8:18 pm, David Kirkby <david.kir...@onetel.net> wrote:
>> If CFLAGS is not being passed to the compiler (which is what I thought
>> before), and LDFLAGS is passed to the compiler, then this could
>> explain why you need to set LDFLAGS.
>
>>From Autoconf manual:
>
> If a compiler option affects only the behavior of the preprocessor
> (e.g., -D name), it should be put into CPPFLAGS instead. If it affects
> only the linker (e.g., -L directory), it should be put into LDFLAGS
> instead. If it affects only the compiler proper, CFLAGS is the natural
> home for it. If an option affects multiple phases of the compiler,
> though, matters get tricky. One approach to put such options directly
> into CC, e.g., CC='gcc -m64'. Another is to put them into both
> CPPFLAGS and LDFLAGS, but not into CFLAGS.
>
> So, a compiler option may affect the link phase and in that case it
> may go into LDFLAGS not in CFLAGS. Another option is to change CC, but
> I would say that is a bit more dangerous.
>
> Juanjo
I think the issue is that gcc is not such a good linker as 'ld'. On my
SPARC at least, gcc suffers from two problems compared to the Sun linker.
* It assumes the objects are 32-bit, even if they are not, so fails if
they are (much the same issue as you get on OS X). 'ld' makes no such
assumption, and tests them.
* gcc creates bigger files than 'ld'
At one point in the build process for ecl, the compiler is called to do
the linking, but the compiler does not inherit the -m64 flag. I tried a
64-bit build, and get -m64 on each line where a file is compiled.
/usr/local/gcc-4.4.1-sun-linker/bin/gcc -I.
-I/export/home/drkirkby/sage/sage-4.1.2.alpha0/spkg/build/ecl-9.8.4.p0/src/build
-I/export/home/drkirkby/sage/sage-4.1.2.alpha0/spkg/build/ecl-9.8.4.p0/src/src/c
-I../ecl/gc -DECL_API
-I/export/home/drkirkby/sage/sage-4.1.2.alpha0/local/include -O2 -m64
-g -Wall -std=gnu99 -fPIC -Dsun4sol2 -c -I./ all_symbols.c -o
all_symbols.o
In file included from
/export/home/drkirkby/sage/sage-4.1.2.alpha0/spkg/build/ecl-9.8.4.p0/src/src/c/all_symbols.d:38:
<SNIP>
Now, when gcc is called to do the linking, it does not have -m64
/usr/local/gcc-4.4.1-sun-linker/bin/gcc
-L/export/home/drkirkby/sage/sage-4.1.2.alpha0/local/lib -o ecl_min
cinit.o c/all_symbols.o -L./ libeclmin.a -leclgmp -leclgc -ldl -lm
-lsocket -lnsl -lintl;\
fi
ld: fatal: file cinit.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to ecl_min
collect2: ld returned 1 exit status
make[1]: *** [ecl_min] Error 1
I noticed something interesting on my SPARC. If one uses 'gcc' to do the
compilation and linking in one stage the executable is more than double
the size of using gcc to create to object file, and 'ld' to link it.
drkir...@smudge:[~] $ gcc -c -m64 hello.c
drkir...@smudge:[~] $ ld -lc -o hello hello.o
drkir...@smudge:[~] $ ls -l hello
-rwxr-xr-x 1 drkirkby other 3616 Sep 9 10:44 hello
Now perform compilation and linking in one stage.
drkir...@smudge:[~] $ gcc -o hello -m64 hello.c
drkir...@smudge:[~] $ ls -l hello
-rwxr-xr-x 1 drkirkby other 8016 Sep 9 10:45 hello
The same happens with 32-bit code. In this case the size increases from
2356 bytes if compilation and linking are performed in two stages, to
5624 bytes if done in one stage.
Given gcc is using the linker in /usr/ccs/bin/ (the 'configure' option
'--with-ld=/usr/ccs/bin/ld' was used when building gcc) and that is the
same linker as called directly, it is odd the file size should be so
different.
I need to do some other things today, but I'll create a new .spkg from
your CVS, export the ABI and see what happens on OS X.
What I also found odd in the previous ecl was that although LDFLAGS was
set in spkg-install, it was never exported. I'm puzzled how that could
have worked.
Dave
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
