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

[William Rivet]

Woot! Michael and Joerg, I have reworked the autotools bits, but
probably still have that messed up. 

Last night I began setting up my development area again for this. I
really could use the second (and third) set of eyes you guys have for
this, since I'm sure I am doing things the hard/wrong way. 

Bug reports on the current autotools scripts probably isn't helpful
unless the new ones I check in are deemed to be worse than what's
there. :-o

I hope to check in tonight, then you all can try it out and let me
know. 



On Tue, 2008-01-08 at 14:38 +0100, Joerg Wunsch wrote:
> 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.)
>