Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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