[Simulavr-devel] Re: Missing -fPIC when compiling code for .so files?

[Joerg Wunsch]

As Joerg Wunsch wrote:

> Indeed, I cannot see a -fPIC anywhere anyhow during the compilation
> before.  How is it supposed to work at all then?  Is it just working
> accidentally on the i386 platform since omitting -fPIC is perhaps
> benign there?

Btw., the actual simulator binary (./src/simulavr) compiled out of
that three appears to run fine.  I started it on the avr-libc simple
LED flasher (PWM ramp up/down) demo in GDB server mode.

Random issues (if you want me to file bugs/patches, just tell me).

The call to aclocal in ./bootstrap should look like

aclocal -I config $ACLOCAL_FLAGS

Background: normally, you can use ACLOCAL_FLAGS to e.g. set up -I
options for automake/aclocal to have it look for m4 files outside of
its own prefix tree.  Since simulavrxx's bootstrap script passes its
own -I option for the config subdirectory, this overrides the
decision, and $ACLOCAL_FLAGS is no longer considered at all so there's
no chance to have it search additional prefix trees.

The assignment of my_binutils_ver in configure.ac does not take into
account that the resulting version string might contain spaces, so
additional quoting is needed.  For example, my avr-binutils here
generate the version string:

2.17 + coff-avr-patch (20050630)

I couldn't figure out though /what/ quoting exactly would be required
to really silence all the warnings. :-/

Are you sure it's really necessary to only search for an AVR version
of the binutils?  According to Ted Roth (because I once had the same
question for AVaRICE), about any installed version should suffice to
read the ELF files, and not much more than this is needed.  On the
mentioned AMD64 Linux machine, I got away with configuring simulavrxx
--with-bfd-path=/usr .  However...

This yields another issue, IMHO a misdesign in the way the AMD64 Linux
systems (and maybe other 64-bit Linuxen as well) are set up: their
native libraries don't live in /usr/lib but rather in /usr/lib64,
because they use /usr/lib for non-native 32-bit compatibility
libraries.  For that reason, IMHO the search for libbfd.a in the root
should first consider $root/lib64 and only then $root/lib.  (OK, even
better, first try finding out whether this actually *is* a 64-bit
system, but I think it's OK to assume only 64-bit systems do have
anything installed at all in $root/lib64.)

-- 
Joerg Wunsch * Development engineer, Atmel Dresden, Germany

Atmel Germany GmbH: Theresienstrasse 2, D-74072 Heilbronn
CEO Robert G. McConnell, Amtsgericht Stuttgart, Registration HRB 106652