[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] Re: Missing -fPIC when compiling code for .so files
From: |
William Rivet |
Subject: |
Re: [Simulavr-devel] Re: Missing -fPIC when compiling code for .so files? |
Date: |
Tue, 08 Jan 2008 18:30:45 -0500 |
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.)
>