From: Jean-Christian de Rivaz <jc@eclis.ch>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Re: buildroot-libtool.patch failed with dbus 1.3.0
Date: Mon, 10 Aug 2009 09:37:00 +0200 [thread overview]
Message-ID: <4A7FCE1C.9060500@eclis.ch> (raw)
In-Reply-To: <20090810001703.396c8e38@surf>
Thomas Petazzoni a ?crit :
> Le Sun, 09 Aug 2009 00:36:36 +0200,
> Jean-Christian de Rivaz <jc@eclis.ch> a ?crit :
>
>>> However, while dbus compilation works successfully now, dbus-glib
>>> still fails to build here:
>>>
>>> /usr/lib/libgobject-2.0.so: could not read symbols: File in wrong
>>> format collect2: ld returned 1 exit status
>>>
>>> So it's a libtool patch issue, again :-)
>> That's strange since I use dbus-glib on a ARM target for about 20
>> applications with the dbus-1.3.0 without that problem. I usually get
>> the wrong format message when I have not do a make clean before
>> switching to an other architecture. Can you post more lines before
>> the error so I can compare with my own build ?
>
> The difference between my setup and your setup is probably that I do
> actually have /usr/lib/libgobject-2.0.so in my filesystem, since the
> libglib2.0-dev package is installed on my distribution. In your case,
> this package is probably not installed, and therefore, libtool doesn't
> think that the correct libgobject library is in /usr/lib.
But I have the usr/lib/libgobject-2.0 on my system:
$ file /usr/lib/libgobject-2.0.so
/usr/lib/libgobject-2.0.so: symbolic link to `libgobject-2.0.so.0.1600.6'
$ file /usr/lib/libgobject-2.0.so.0.1600.6
/usr/lib/libgobject-2.0.so.0.1600.6: ELF 64-bit LSB shared object,
x86-64, version 1 (SYSV), dynamically linked, stripped
> I've actually tried this hypothesis on another package (webkit that was
> failing in a similar way on libenchant), and remove the development
> files in /usr/lib, and the link succeeded.
>
> It seems to be hard to convince libtool that /usr/lib does *not*
> contain anything interesting.
Yes. This is a common problem with libtool while cross-compiling.
Sometime the problem are in the *.la files installed into the staging.
Best regards,
Jean-Christian de Rivaz
prev parent reply other threads:[~2009-08-10 7:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-07 19:52 [Buildroot] buildroot-libtool.patch failed with dbus 1.3.0 Jean-Christian de Rivaz
2009-08-07 20:17 ` Thomas Petazzoni
2009-08-07 21:40 ` [Buildroot] [PATCH] " Jean-Christian de Rivaz
2009-08-07 22:43 ` Thomas Petazzoni
2009-08-07 23:07 ` Jean-Christian de Rivaz
2009-08-08 18:09 ` Thomas Petazzoni
2009-08-08 22:36 ` Jean-Christian de Rivaz
2009-08-08 22:59 ` Thomas Petazzoni
2009-08-10 7:29 ` Jean-Christian de Rivaz
2009-08-10 7:39 ` Jean-Christian de Rivaz
2009-08-09 22:17 ` Thomas Petazzoni
2009-08-10 7:37 ` Jean-Christian de Rivaz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A7FCE1C.9060500@eclis.ch \
--to=jc@eclis.ch \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox