All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] RTLD_DEEPBIND and uClibc
Date: Thu, 17 Jan 2013 00:00:37 +0100	[thread overview]
Message-ID: <20130117000037.39ccc628@skate> (raw)
In-Reply-To: <50F6A26D.4030607@petroprogram.com>

Dear Stefan Fr?berg,

On Wed, 16 Jan 2013 14:51:57 +0200, Stefan Fr?berg wrote:

> Yesterday evening I managed to compile cairo-dock-core and
> cairo-dock-plugins
> version 3.1.2 for buildroot 2012.08.
> 
> It's a nice, lightweight (made with C), Mac OSX feeling application
> dock.
> 
> The problem is that cairo-dock-core has the following line in it's
> code:
> 
> pCairoDockModule->handle = dlopen (pCairoDockModule->cSoFilePath,
> RTLD_LAZY | RTLD_LOCAL | RTLD_DEEPBIND);
> 
> And uClibc does not have RTLD_DEEPBIND. Removing it will allow
> cairo-dock to compile but the result is
> that cairo-dock plugins won't work.

Strange, from a quick look, it seems that it is used to get a single
symbol, called "pre_init" from each plugin. I don't see how pre_init
may conflict with some other global symbol, which is what RTLD_DEEPBIND
is all about. But I've only done a 5 minutes look at cairo-dock code,
so I might have missed the point.

> Is there any workaround to this RTLD_DEEPBIND stuff ?

Since you're using a big stuff like X.org, why do you persist in using
uClibc? Using glibc or eglibc would make a very small size difference,
and would avoid the hassle of all those small, but annoying, uClibc
limitations.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-01-16 23:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-16 12:51 [Buildroot] RTLD_DEEPBIND and uClibc Stefan Fröberg
2013-01-16 23:00 ` Thomas Petazzoni [this message]
2013-01-17  0:36   ` Stefan Fröberg
2013-01-17  8:31     ` Thomas Petazzoni
2013-01-17 13:50       ` Stefan Fröberg
2013-01-17 16:18         ` Alex Bradbury
2013-01-17 16:51           ` Stefan Fröberg
2013-01-17 17:09             ` Alex Bradbury
2013-01-17 18:48               ` Stefan Fröberg
2013-01-17 22:03           ` Peter Korsgaard
2013-01-17 17:44         ` Yann E. MORIN
2013-01-17 18:47           ` Stefan Fröberg
2013-01-17 20:38             ` Yann E. MORIN
2013-01-17 20:41               ` Yann E. MORIN
2013-01-17 20:51               ` Stefan Fröberg
2013-01-17 21:17                 ` Yann E. MORIN
2013-01-17 21:23                   ` Stefan Fröberg

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=20130117000037.39ccc628@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.