Re: Compilation problems on Ubuntu 64-bit

[Marcus Clyne <maccaday at gmail dot com>]

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.