building LTO plugin fails for x86_64-unknown -linux-gnu

[Rainer Emrich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Guenther schrieb:
> On Sun, Oct 11, 2009 at 6:21 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich
>> <rainer@emrich-ebersheim.de> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> libtool: link: gcc -shared  .libs/lto-plugin.o
>>> -
>>> -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/install/lib64
>> is there a libiberty in that path?
>>
>>> - -lelf
>>> -
>>> -L/SCRATCH/tmp.dYgZv17836/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.5.0/gcc-4.5.0/libiberty/pic
>> it's supposed to be picked up from here instead.
> 
> Thus, I guess
> 
> Index: lto-plugin/Makefile.am
> ===================================================================
> --- lto-plugin/Makefile.am	(revision 152638)
> +++ lto-plugin/Makefile.am	(working copy)
> @@ -16,4 +16,4 @@ AM_CFLAGS = -Wall -Werror
>  libexecsub_LTLIBRARIES = liblto_plugin.la
> 
>  liblto_plugin_la_SOURCES = lto-plugin.c
> -liblto_plugin_la_LIBADD = $(LIBELFLIBS) -L../libiberty/pic -liberty
> +liblto_plugin_la_LIBADD = $(LIBELFLIBS) ../libiberty/pic/libiberty.a
> 
> would fix it.
> 
> Richard.
> 
Yes, I think that should fix the issue. I think it's a good idea in general to
make sure that the library is picked up from within the build tree.

So, for testing this change I have to regenerate the dependent files with
automake, no?

Rainer


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrS7noACgkQoUhjsh59BL4b7ACfV6hhQBRPOzpHTZYvwkUFRHP/
tqoAnA3ek9q/wIvbhUCRDqiK0z8dYDXt
=oh/6
-----END PGP SIGNATURE-----