Mailing List Archive: Gentoo: OSX

[PREFIX] LD_LIBRARY_PATH issue

Index | Next | Previous | View Threaded

grobian at gentoo

Sep 6, 2006, 5:58 AM

Post #1 of 6 (1958 views)
Permalink

[PREFIX] LD_LIBRARY_PATH issue

Hi all,

While trying to get "system" emerged, I ran into a problem with perl.
For a change, perl doesn't seem to be the problem itself to me :D

The problem is that perl links against gdbm which succeeds fine, but
then when running the linked executable, it fails to find (the right)
gdbm. I think that all packages before perl just didn't link against
dynamic libraries, or that my native system happened to have the same or
sufficient libraries installed. The problem is of course that the
dynamic (runtime) linker has to know that dynamic libraries exist on
other paths than the usual system paths. This is typically done using
the LD_LIBRARY_PATH environment variable.

I made a temporary hack using a profile.bash file to set the
LD_LIBRARY_PATH for portage itself. The whole issue triggered some
questions for me:
- should portage "inject" LD_LIBRARY_PATH itself in prefix to make sure
its environment is correct?
- all our shells should set LD_LIBRARY_PATH, right?
- if the shell sets it, portage uses it, does it? If so, the inject
should not be necessary if you require a portage built shell to be
used. During bootstrap this is a problem (the phase I'm in)

comments?

--
Fabian Groffen
Gentoo for Mac OS X Project
--
gentoo-osx[at]gentoo.org mailing list

michael.haubenwallner at salomon

Sep 6, 2006, 6:37 AM

Post #2 of 6 (1884 views)
Permalink

Re: [PREFIX] LD_LIBRARY_PATH issue [In reply to]

Hi,

this is one reason why i never stopped using my toolsbox to bootstrap
portage: it creates environment-scripts, besides others containing those
LD_LIBRARY_PATH bits. And well, this is called SHLIB_PATH on HP-UX and
LIBPATH on AIX.

And for the running portage, i've some patches to let portage
dynamically extend the list of extendable variables with values
from /etc/env.d/ files.
In combination with some baselayout-packages, which do those
configuration through /etc/env.d/, i'm able to inform portage to dupe
the value of LDPATH into LD_LIBRARY_PATH, SHLIB_PATH or LIBPATH,
depending on the profile, which unmask the correct baselayout for a
specific platform.

Patches/ebuilds coming soon ...

-- haubi

On Wed, 2006-09-06 at 14:58 +0200, Grobian wrote:
> Hi all,
>
> While trying to get "system" emerged, I ran into a problem with perl.
> For a change, perl doesn't seem to be the problem itself to me :D
>
> The problem is that perl links against gdbm which succeeds fine, but
> then when running the linked executable, it fails to find (the right)
> gdbm. I think that all packages before perl just didn't link against
> dynamic libraries, or that my native system happened to have the same or
> sufficient libraries installed. The problem is of course that the
> dynamic (runtime) linker has to know that dynamic libraries exist on
> other paths than the usual system paths. This is typically done using
> the LD_LIBRARY_PATH environment variable.
>
> I made a temporary hack using a profile.bash file to set the
> LD_LIBRARY_PATH for portage itself. The whole issue triggered some
> questions for me:
> - should portage "inject" LD_LIBRARY_PATH itself in prefix to make sure
> its environment is correct?
> - all our shells should set LD_LIBRARY_PATH, right?
> - if the shell sets it, portage uses it, does it? If so, the inject
> should not be necessary if you require a portage built shell to be
> used. During bootstrap this is a problem (the phase I'm in)
>
> comments?
>
> --
> Fabian Groffen
> Gentoo for Mac OS X Project

--
gentoo-osx[at]gentoo.org mailing list

grobian at gentoo

Sep 6, 2006, 12:20 PM

Post #3 of 6 (1879 views)
Permalink

Re: [PREFIX] LD_LIBRARY_PATH issue [In reply to]

On 06-09-2006 15:37:31 +0200, Michael Haubenwallner wrote:
> Hi,
>
> this is one reason why i never stopped using my toolsbox to bootstrap
> portage: it creates environment-scripts, besides others containing those
> LD_LIBRARY_PATH bits. And well, this is called SHLIB_PATH on HP-UX and
> LIBPATH on AIX.

With respect, but I think the reason we don't use toolbox is because I
never got it to bootstrap anything :(

> And for the running portage, i've some patches to let portage
> dynamically extend the list of extendable variables with values
> from /etc/env.d/ files.
> In combination with some baselayout-packages, which do those
> configuration through /etc/env.d/, i'm able to inform portage to dupe
> the value of LDPATH into LD_LIBRARY_PATH, SHLIB_PATH or LIBPATH,
> depending on the profile, which unmask the correct baselayout for a
> specific platform.

Ahh... I knew the problem was bigger than it looked :)

> Patches/ebuilds coming soon ...

Much appreciated

--
Fabian Groffen
Gentoo for Mac OS X Project
--
gentoo-osx[at]gentoo.org mailing list

cchan at spikesource

Sep 6, 2006, 12:45 PM

Post #4 of 6 (1880 views)
Permalink

RE: [PREFIX] LD_LIBRARY_PATH issue [In reply to]

Looking forward to the patches, I'm just sourcing environment scripts as
well.

-----Original Message-----
From: Michael Haubenwallner [mailto:michael.haubenwallner[at]salomon.at]
Sent: Wednesday, September 06, 2006 6:38 AM
To: gentoo-osx[at]lists.gentoo.org
Subject: Re: [gentoo-osx] [PREFIX] LD_LIBRARY_PATH issue

Hi,

this is one reason why i never stopped using my toolsbox to bootstrap
portage: it creates environment-scripts, besides others containing those
LD_LIBRARY_PATH bits. And well, this is called SHLIB_PATH on HP-UX and
LIBPATH on AIX.

And for the running portage, i've some patches to let portage
dynamically extend the list of extendable variables with values
from /etc/env.d/ files.
In combination with some baselayout-packages, which do those
configuration through /etc/env.d/, i'm able to inform portage to dupe
the value of LDPATH into LD_LIBRARY_PATH, SHLIB_PATH or LIBPATH,
depending on the profile, which unmask the correct baselayout for a
specific platform.

Patches/ebuilds coming soon ...

-- haubi

On Wed, 2006-09-06 at 14:58 +0200, Grobian wrote:
> Hi all,
>
> While trying to get "system" emerged, I ran into a problem with perl.
> For a change, perl doesn't seem to be the problem itself to me :D
>
> The problem is that perl links against gdbm which succeeds fine, but
> then when running the linked executable, it fails to find (the right)
> gdbm. I think that all packages before perl just didn't link against
> dynamic libraries, or that my native system happened to have the same or
> sufficient libraries installed. The problem is of course that the
> dynamic (runtime) linker has to know that dynamic libraries exist on
> other paths than the usual system paths. This is typically done using
> the LD_LIBRARY_PATH environment variable.
>
> I made a temporary hack using a profile.bash file to set the
> LD_LIBRARY_PATH for portage itself. The whole issue triggered some
> questions for me:
> - should portage "inject" LD_LIBRARY_PATH itself in prefix to make sure
> its environment is correct?
> - all our shells should set LD_LIBRARY_PATH, right?
> - if the shell sets it, portage uses it, does it? If so, the inject
> should not be necessary if you require a portage built shell to be
> used. During bootstrap this is a problem (the phase I'm in)
>
> comments?
>
> --
> Fabian Groffen
> Gentoo for Mac OS X Project

--
gentoo-osx[at]gentoo.org mailing list

--
gentoo-osx[at]gentoo.org mailing list

michael.haubenwallner at salomon

Sep 7, 2006, 2:26 AM

Post #5 of 6 (1878 views)
Permalink

Re: [PREFIX] LD_LIBRARY_PATH issue [In reply to]

On Wed, 2006-09-06 at 21:20 +0200, Grobian wrote:
> On 06-09-2006 15:37:31 +0200, Michael Haubenwallner wrote:
> With respect, but I think the reason we don't use toolbox is because I
> never got it to bootstrap anything :(

IIRC you did not manage to inform it where to download things from.
But it's ok for me to have a bootstrap-script in the tree, even i don't
plan to use it.

Well, here are the two portage patches for dynamically duping
environment values. Patch-Numbers fit into my previous mail containing a
bunch of other patches [1].

[06-env-conf+ext.patch]
Let portage create /etc/env.conf containing somewhat a dump of the
environment bits found in /etc/env.d/*, to be read by /sbin/extenv, see
below (the baselayout-prefix.ebuild).

[07-env-dup.patch]
Interpret variables PORTAGE_ENVDUP* found in /etc/env.d/*, to dupe
values from one environment variable to another. Example is to dupe
values from LDPATH to LD_LIBRARY_PATH, SHLIB_PATH or LIBPATH, see below
(the baselayout-linux.ebuild).

[baselayout-prefix-0.1.ebuild]
[baselayout-prefix-0.1_files.tar.gz]
Installs these (eprefix'ed) files:
/etc/profile
The entry point for this eprefix.
Utilizes /sbin/extenv to add values the environment.
It also sets up an alias 'eenv-clear', which sources /etc/unprofile,
to be able to remove all the environment values for this eprefix.
/sbin/extenv
Interprets /etc/env.conf and generates a list of shell commands (for
sh and csh) adding values to the environment.
/etc/unprofile
The exit point from this eprefix.
Also utilizes /sbin/extenv to remove values from the environment.
Also unaliases 'eenv-clear'.
/etc/env.d/98secondary
Contains values for PATH,ROOTPATH,LDPATH,... for this eprefix.
/var/spool/emerge/doasroot
Create it as empty file, currently not in use.
Intention is to collect commands from enewuser/enewgroup/... when
not run as real root (uid 0).

Additionally, two symlinks are created:
/sbin/functions.sh -> /usr/lib/portage/bin/isolated-functions.sh
/etc/init.d/functions.sh -> /sbin/functions.sh

I use /usr/lib/portage/bin/isolated-functions.sh because i did not know
better where to get those functions.sh from.

[baselayout-linux-0.1.ebuild]
Installs only one file:
/etc/env.d/99system
Only contains two lines:
PORTAGE_ENVDUP="LDPATH"
PORTAGE_ENVDUP_LDPATH="LD_LIBRARY_PATH"
This configures portage (with 07-env-dup.patch) to dupe collected
values from LDPATH into LD_LIBRARY_PATH.

Idea is to let make.profile symlink unmask different packages for hpux
and aix, to dupe LDPATH value into SHLIB_PATH and LIBPATH respectively.

Comments welcome!

[1] http://thread.gmane.org/gmane.linux.gentoo.macosx/1080/focus=1080

-haubi-
--
Michael Haubenwallner SALOMON Automation GmbH
Forschung & Entwicklung A-8114 Friesach bei Graz
mailto:michael.haubenwallner[at]salomon.at http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html

Attachments:

06-env-conf+ext.patch (8.14 KB)

07-env-dup.patch (2.65 KB)

baselayout-prefix-0.1.ebuild (1.59 KB)

baselayout-prefix-0.1_files.tar.gz (2.12 KB)

baselayout-linux-0.1.ebuild (0.66 KB)

michael.haubenwallner at salomon

Sep 7, 2006, 5:43 AM

Post #6 of 6 (1877 views)
Permalink

Re: [PREFIX] LD_LIBRARY_PATH issue [In reply to]

(Apologies if you get this mail a second time - first i tried with
baselayout-prefix/files attached as a tar.gz-ball and did not see this
mail in gmane.org for hours. Now these files are attached separately.)

On Wed, 2006-09-06 at 21:20 +0200, Grobian wrote:
> On 06-09-2006 15:37:31 +0200, Michael Haubenwallner wrote:
> With respect, but I think the reason we don't use toolbox is because I
> never got it to bootstrap anything :(

IIRC you did not manage to inform it where to download things from.
But it's ok for me to have a bootstrap-script in the tree, even i don't
plan to use it.

Well, here are the two portage patches for dynamically duping
environment values. Patch-Numbers fit into my previous mail containing a
bunch of other patches [1].

[06-env-conf+ext.patch]
Let portage create /etc/env.conf containing somewhat a dump of the
environment bits found in /etc/env.d/*, to be read by /sbin/extenv, see
below (the baselayout-prefix.ebuild).

[07-env-dup.patch]
Interpret variables PORTAGE_ENVDUP* found in /etc/env.d/*, to dupe
values from one environment variable to another. Example is to dupe
values from LDPATH to LD_LIBRARY_PATH, SHLIB_PATH or LIBPATH, see below
(the baselayout-linux.ebuild).

[baselayout-prefix-0.1.ebuild]
files: [0.1-extenv] [0.1-inputrc] [0.1-profile] [0.1-unprofile]
Installs these files:
/etc/profile
The entry point for this eprefix.
Utilizes /sbin/extenv to add values the environment.
It also sets up an alias 'eenv-clear', which sources /etc/unprofile,
to be able to remove all the environment values for this eprefix.
/sbin/extenv
Interprets /etc/env.conf and generates a list of shell commands (for
sh and csh) adding values to the environment.
/etc/unprofile
The exit point from this eprefix.
Also utilizes /sbin/extenv to remove values from the environment.
Also unaliases 'eenv-clear'.
/etc/env.d/98secondary
Contains values for PATH,ROOTPATH,LDPATH,... for this eprefix.
/var/spool/emerge/doasroot
Create it as empty file, currently not in use.
Intention is to collect commands from enewuser/enewgroup/... when
not run as real root (uid 0).
/etc/inputrc
Some maybe out-of-date inputrc, could be unneccesary here.

Additionally, two symlinks are created:
/sbin/functions.sh -> /usr/lib/portage/bin/isolated-functions.sh
/etc/init.d/functions.sh -> /sbin/functions.sh

I use /usr/lib/portage/bin/isolated-functions.sh because i did not know
better where to get those /sbin/functions.sh from.

[baselayout-linux-0.1.ebuild]
Installs only one file:
/etc/env.d/99system
Only contains two lines:
PORTAGE_ENVDUP="LDPATH"
PORTAGE_ENVDUP_LDPATH="LD_LIBRARY_PATH"
This configures portage (with 07-env-dup.patch) to dupe collected
values from LDPATH into LD_LIBRARY_PATH.

Idea is to let make.profile symlink unmask different packages for hpux
and aix, to dupe LDPATH value into SHLIB_PATH and LIBPATH respectively.

Comments welcome!

[1] http://thread.gmane.org/gmane.linux.gentoo.macosx/1080/focus=1080

-haubi-
--
Michael Haubenwallner SALOMON Automation GmbH
Forschung & Entwicklung A-8114 Friesach bei Graz
mailto:michael.haubenwallner[at]salomon.at http://www.salomon.at
No HTML/MIME please, see http://expita.com/nomime.html

Attachments:

06-env-conf+ext.patch (8.14 KB)

07-env-dup.patch (2.65 KB)

baselayout-prefix-0.1.ebuild (1.59 KB)

baselayout-linux-0.1.ebuild (0.66 KB)

0.1-extenv (3.71 KB)

0.1-inputrc (0.98 KB)

0.1-profile (0.94 KB)

0.1-unprofile (0.69 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com