Re: Compilation problems on Ubuntu 64-bit

> 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.
>