This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC3.1 Solaris 64bit shared libraries - bad ELF flag 2


I have made some progress on this. It seems that I need to compile the
objects as follows:

	gcc -m64 -Wa,-TSO -c -o f64.o f.c 
	ld -Bdynamic -G -o f64.so f64.o -lm
	gcc -m64 -o main64 main.c ./f64.so -lm

This changes the flags of f64.so from EF_SPARCV9_RMO (relaxed memory object)
to EF_SPARCV9_TSO (total storage object). You can see the value of the flag
with elfdump -e ./f64.so. There is more information in the Solaris Linker
and Libraries Guide but not enough to explain to me what this really all
about. Lets hope this is enough to get me going.

Incidentally I cannot build a shared object with "gcc -m64 -G -o f64.so
f64.o -lm" because gcc then pulls in a whole bunch of EF_SPARCV9_RMO objects
from /usr/local/lib and the shared object becomes RMO. It doesnt matter if
main is compiled as RMO. Probably I should rebuild gcc/gas to make TSO the
default.

Regards
John

--------------------- Original message ------------------------------
Hi all,
I am having difficulty building a working shared 64 bit object. I am using
GNU as (from binutils 2.11.2) and the Solaris8 ld.
GCC 3.1 was built with ../configure --with-as=/usr/local/bin/as
--with-ld=/usr/ccs/bin/ld

In the example below I have compiled a really short test program in 32bits
with a shared object, 64bits with a shared object and 64 bits without a
shared object. The 64 bit shared binary fails to run with a message about
the ELF flags.

Sample program:
f.c:
	#include <stdio.h>
	#include <math.h>
	int f() {printf("Test %g\n", sin((double)0.5) );return 0;}
main.c:
	main() { f(); }
compilation (64bit)
	gcc -m64 -c -o f64.o f.c 
	ld -Bdynamic -G -o f64.so f64.o -lm
	gcc -m64 -o main64 main.c ./f64.so -lm

	gcc -m64 -o main64static main.c f64.o -lm
compilation(32bit)
	gcc -c -o f32.o f.c 
	ld -Bdynamic -G -o f32.so f32.o -lm 
	gcc -o main32 main.c ./f32.so -lm 

output
	$ ./main32
	Test 0.479426
	$ ./main64
	ld.so.1: ./main64: fatal: ./f64.so: bad ELF flags value: 2
<--------------
	Killed
	$ ./main64static
	Test 0.479426
file main32 main64* *.so
	main32:         ELF 32-bit MSB executable SPARC Version 1,
dynamically linked, not stripped
	main64:         ELF 64-bit MSB executable SPARCV9 Version 1,
dynamically linked, not stripped
	main64static:   ELF 64-bit MSB executable SPARCV9 Version 1,
dynamically linked, not stripped
	f32.so:         ELF 32-bit MSB dynamic lib SPARC Version 1,
dynamically linked, not stripped
	f64.so:         ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
dynamically linked, not stripped
ldd output
	$ ldd ./f32.so
	        libm.so.1 =>     /usr/lib/libm.so.1
	        libc.so.1 =>     /usr/lib/libc.so.1
	        libdl.so.1 =>    /usr/lib/libdl.so.1
	        /usr/platform/SUNW,UltraSPARC-IIi-cEngine/lib/libc_psr.so.1
	$ ldd ./f64.so
	$ 

I am also curious about the ldd result - the reason for calling sin() was to
require libm so that ldd on f32.so would produce interesting output. ldd on
f64.so doesnt produce any output.

I am stuck on this. I really need a shared 64 bit library so I hope somebody
can tell me what to do next.

Regards
John


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]