Update:
I've now tried removing the -lsimpl from the commands, but am still
getting the following error when calling using execv(p):
(on x86-64)
../lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crt1.o: In function
`_start':
/build/buildd/glibc-2.9/csu/../sysdeps/x86_64/elf/start.S:109: undefined
reference to `main'
collect2: ld returned 1 exit status
(on x86)
../lib/gcc/x86_64-linux-gnu/4.3.3/../../../../lib/crt1.o: In function
`_start':
/build/buildd/glibc-2.9/csu/../sysdeps/i386/elf/start.S:115: undefined
reference to `main'
collect2: ld returned 1 exit status
However, when compiling from the shell, it works no problem.
These were both attempted on Ubuntu 9.04. My old computer had Ubuntu
8.04 on, and worked, and AFAIK I didn't change any code between
switching over to the new computer.
I've tried looking for whether this is an OS issue, but haven't found a
definitive answer yet. The above errors are not related to any of my
code, but to that used by gcc/ld.
I think I need to add something to the environment, but am not sure what.
Any ideas would be gratefully received.
Marcus.
Marcus Clyne wrote:
Hi,
Kai Ruottu wrote:
Marcus Clyne wrote:
I'm trying to create a shared object file calling GCC using execvp,
but am getting some errors.
Does it work directly from the shell?
Yes
First - .o creation, using the following options:
---------------------
-fPIC -o /tmp/simpl-so/objs/10.o -I/simpl/dev/src
-I/simpl/dev/src/core \
-I/simpl/dev/src/include -c /t/bufout.c
---------------------
Would the result be identical with these put into the usual command
line, with the '.o' got via execvp? Seen with 'size', 'objdump -p',
'readelf -h' etc.
No, though I'm not sure why. The following results for readelf -h are:
(shell created)
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 1400 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 13
Section header string table index: 10
(execvp created)
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 1384 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 13
Section header string table index: 10
This seems to go ok, then calling with the following options:
-------------------------
-fPIC -shared -o /tmp/simpl-so/objs/10.so \
> /tmp/simpl-so/objs/10.o -lsimpl
-------------------------
And what the 'manual' linking would tell? Does it succeed?
If you mean by calling gcc from the shell, yes, it does work.
COLLECT_GCC_OPTIONS='-v' '-shared' '-o' '/tmp/simpl-so/objs/10.so'
'-mtune=generic'
libsimpl is compiled using fPIC too.
And with the same '-mtune=generic' ?
Yes - I hadn't changed it, but I also set it to 'generic' explicitly,
and the new errors (which are different from the original errors) are
still the same - I put these in a separate post.
-shared
Produce a shared object which can then be linked with other objects to
form an executable. Not all systems support this option. For
predictable results, you must also specify the same set of options
that were used to generate code (‘-fpic’, ‘-fPIC’, or model
suboptions) when you specify this option.
I'm actually creating so's that will be linked using dlopen etc - not
sure if this makes a difference or not.
In any case, it works ok when I use the shell but not when I use
execv(p) to call gcc.
Thanks,
Marcus.
