[Linux-ia64] Location of absolute IA32 shared objects.

[Linux-ia64] Location of absolute IA32 shared objects.

[Don Dugger]

David-

No, you can actually check the architecture type in `dlopen' and discover
that you are trying to use the wrong library.  (That's what I used to do
before you discovered the better way of using the `/etc/ld.so.cache'.)

Having said that I don't have a real strong opinion on this.  You could
try `/usr/ia32' first and, if there is a file there then it must be the
one you want and if it isn't there then try the original path.  Or, try
the orignal path and, if it isn't there or has the wrong architecture,
try the modified path.  Either way works.

On Wed, Sep 05, 2001 at 09:49:24AM -0700, David Mosberger wrote:
> >>>>> On Wed, 5 Sep 2001 10:47:42 -0600, Don Dugger <n0ano@valinux.com> said:
> 
>   Don> Bill raises an interesting problem.  I'd like to suggest a
>   Don> solution and see what everyone thinks.  Since all of the shared
>   Don> objects are loaded by code in `ld-linux.so' I can modify the
>   Don> IA32 version of that library to first try an absolute path and,
>   Don> if that fails, because it's missing or has the wrong
>   Don> architecture, to then tack on a unique prefix, either something
>   Don> like `/usr/ia32' or the contents of an environment variable
>   Don> like `LD_IA32_PATH'.
> 
> Wouldn't you have to try the prefix first?  Otherwise, you might end
> up picking up an ia64 library.
> 
> 	--david
> 
> 
> 
> _______________________________________________
> ia64-list mailing list
> ia64-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/ia64-list

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Christoph Hellwig]

On Wed, Sep 05, 2001 at 02:53:11PM -0600, Don Dugger wrote:
> 2)  How do we deal with absolute path names in IA32 binaries?  This is
> the question I'm concerned with right now.  The sad reality of life is
> that there are rogue (I use the term `rogue' with tongue firmly planted
> in check) IA32 binaries that have hard coded absolute paths to certain
> libraries.  I think we all agree that `standard' libraries  must be IA64
> objects and, therefore, we need to find a way to deal with these
> rogue IA32 programs if we want them to run.
> 
> I have a proposed solution to 2 but it's not perfect.  I was kind of hoping
> that someone had a better idea but it doesn't look like it.  Unless someone
> comes up with a brainstorm I'll implement my idea and at least we should
> be able to run the rogue IA32 programs we know about.

Please take a look at include/asm-*/namei.h - we can define an emulation
prefix for Linux/i386 (e.g. /emul/linux32) and all lookups will be tried
there before falling back to the native FS,  This appropeach is already
used by the MIPS and SPARC ports and by linux-abi for i386.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

[Linux-ia64] Location of absolute IA32 shared objects.

[Don Dugger]

I think there are two issues here, both important, but I was only trying
to address the second question:

1)  Exactly where do we put IA32 objects.  Personally I don't care,
to me this is just an arbitrary character string that needs to be added
to path names and I use which ever one everybody agrees to.  Unfortunately
the Itanium specific ABI suggests where to put them but it doesn't
explicitly specify where.  The ABI only talks about IA64 objects, it
doesn't explicitly deal with IA32 objects.  A quick read of section
5.3.1 would say to me that `/usr/lib/ia32', `/usr/lib/ia32l32',
`/usr/lib/ia32l' or `/usr/lib/l32' are all possible interpretations of
where IA32 objects are placed.  Again, I don't care, pick one.  Doug
is right, this is something that should be coordinated with the LSB.

2)  How do we deal with absolute path names in IA32 binaries?  This is
the question I'm concerned with right now.  The sad reality of life is
that there are rogue (I use the term `rogue' with tongue firmly planted
in check) IA32 binaries that have hard coded absolute paths to certain
libraries.  I think we all agree that `standard' libraries  must be IA64
objects and, therefore, we need to find a way to deal with these
rogue IA32 programs if we want them to run.

I have a proposed solution to 2 but it's not perfect.  I was kind of hoping
that someone had a better idea but it doesn't look like it.  Unless someone
comes up with a brainstorm I'll implement my idea and at least we should
be able to run the rogue IA32 programs we know about.

On Sep 05, 2001 at 12:20:01PM -0700, Sunil Saxena wrote:
> Have you folks looked at the "UNIX System V Application Binary Interface" at
> http://developer.intel.com/design/IA-64/ ?  Section 5.3.1 suggests locations
> for the libraries.
> 
> Thanks
> Sunil
> 
> -----Original Message-----
> From: Doug Beattie [mailto:dbb@caldera.com]
> Sent: Wednesday, September 05, 2001 10:57 AM
> To: Don Dugger
> Cc: Bill Nottingham; ia64-list@redhat.com; linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] Re: Wolverine RPMs
> 
> 
> Don and others:
> 
> Let's not forget what might need to be considered to allow LSB 32 bit
> compliant apps on IA64. Even though no one may ever certify for this,
> it would be nice to find out and follow a convention that would
> benefit all.
> 
> Doug
> 

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[David Mosberger]

>>>>> On Wed, 5 Sep 2001 22:47:17 +0200, Christoph Hellwig <hch@ns.caldera.de> said:

  Christoph> Please take a look at include/asm-*/namei.h - we can
  Christoph> define an emulation prefix for Linux/i386
  Christoph> (e.g. /emul/linux32) and all lookups will be tried there
  Christoph> before falling back to the native FS, This appropeach is
  Christoph> already used by the MIPS and SPARC ports and by linux-abi
  Christoph> for i386.

I don't particularly like changing filenames underneath the user, but
as far as I can see, it's the most systematic way to fix absolute
naming issues.  Unless someone has serious objections to this, I'll
make this change.  As far as I can see, neither LSB nor FHS address
the issue of where to place emulation files, so I'll propose a prefix
of "/emul/ia32-linux/" as a starter.  Any objections?

(Note to Sunil: the IA-64 ABI is of no help here because we're talking
 about files that are outside the standard library search paths and
 the issue is not really limited to shared objects only.)

	--david

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Ulrich Drepper]

David Mosberger <davidm@hpl.hp.com> writes:

> As far as I can see, neither LSB nor FHS address the issue of where
> to place emulation files, so I'll propose a prefix of
> "/emul/ia32-linux/" as a starter.  Any objections?

Not that I care, but this is clearly a place for a new /proc entry
which can be changed by the sysadmin.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Christoph Hellwig]

On Mon, Sep 10, 2001 at 09:30:02PM -0700, Ulrich Drepper wrote:
> David Mosberger <davidm@hpl.hp.com> writes:
> 
> > As far as I can see, neither LSB nor FHS address the issue of where
> > to place emulation files, so I'll propose a prefix of
> > "/emul/ia32-linux/" as a starter.  Any objections?
> 
> Not that I care, but this is clearly a place for a new /proc entry
> which can be changed by the sysadmin.

If that is the general consensus I will globally move the emul prefix
stuff to /proc based values instead of compile-time defines.

Any objections?

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Mark Goodwin]

On Tue, 11 Sep 2001, Christoph Hellwig wrote:

> On Mon, Sep 10, 2001 at 09:30:02PM -0700, Ulrich Drepper wrote:
> > David Mosberger <davidm@hpl.hp.com> writes:
> > 
> > > As far as I can see, neither LSB nor FHS address the issue of where
> > > to place emulation files, so I'll propose a prefix of
> > > "/emul/ia32-linux/" as a starter.  Any objections?
> > 
> > Not that I care, but this is clearly a place for a new /proc entry
> > which can be changed by the sysadmin.
> 
> If that is the general consensus I will globally move the emul prefix
> stuff to /proc based values instead of compile-time defines.
> 
> Any objections?

RPM installs for ia32 apps/libs will need to use --prefix `cat /proc/ia32prefix`
or whatever. If sysadmin subsequently changes the prefix, it wont work. Would a
better solution be an ia32 specifc version of /etc/ld.so.conf? Or perhaps the
/proc file should allow multiple search paths?

-- Mark

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Christoph Hellwig]

On Tue, Sep 11, 2001 at 09:25:39PM +1000, Mark Goodwin wrote:
> RPM installs for ia32 apps/libs will need to use --prefix `cat /proc/ia32prefix`
> or whatever.
> If sysadmin subsequently changes the prefix, it wont work.
> better solution be an ia32 specifc version of /etc/ld.so.conf? Or perhaps the
> /proc file should allow multiple search paths?

That was discussed before - the real issue are IA32 programms that hardcode
pathes.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[David Mosberger]

>>>>> On 10 Sep 2001 21:30:02 -0700, Ulrich Drepper <drepper@redhat.com> said:

  Uli> David Mosberger <davidm@hpl.hp.com> writes:
  >> As far as I can see, neither LSB nor FHS address the issue of
  >> where to place emulation files, so I'll propose a prefix of
  >> "/emul/ia32-linux/" as a starter.  Any objections?

  Uli> Not that I care, but this is clearly a place for a new /proc
  Uli> entry which can be changed by the sysadmin.

I'd have thought that this should be treated like "/": an unchanging
prefix.  Mount, symlinks, and chroot are your friend.  Making it
variable makes installation harder, as others have pointed out.  But
it's not like I care a whole lot (as long as ia64 kernel performance
isn't impacted noticably).

	--david

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Doug Beattie]

I just noticed a comment was posted on 2001-08-15 to the LSB tracking
task on this subject, that a post to fhs-discuss gave the solution to
the question of where ia32 vs ia64 libs should be placed.

`The /lib directory on x86 and IA64 will always contain the 32bit
libraries. IA64 systems should put their libraries in /lib64.' "This
way we don't need any special install hooks in the system, installer,
and package. It's all hardcoded." 

The description above are a paraphrase and direct quote from the post
to LSB task number 32642 that was used to track what should be done
for LSB compatibility.

Doug

David Mosberger wrote:
> 
> >>>>> On 10 Sep 2001 21:30:02 -0700, Ulrich Drepper <drepper@redhat.com> said:
> 
>   Uli> David Mosberger <davidm@hpl.hp.com> writes:
>   >> As far as I can see, neither LSB nor FHS address the issue of
>   >> where to place emulation files, so I'll propose a prefix of
>   >> "/emul/ia32-linux/" as a starter.  Any objections?
> 
>   Uli> Not that I care, but this is clearly a place for a new /proc
>   Uli> entry which can be changed by the sysadmin.
> 
> I'd have thought that this should be treated like "/": an unchanging
> prefix.  Mount, symlinks, and chroot are your friend.  Making it
> variable makes installation harder, as others have pointed out.  But
> it's not like I care a whole lot (as long as ia64 kernel performance
> isn't impacted noticably).
> 
>         --david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Douglas B. Beattie
------------------
Linux Test Architect - Caldera, Inc.
dbb@caldera.com

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[David Mosberger]

>>>>> On Fri, 14 Sep 2001 08:30:22 -0600, Doug Beattie <dbb@caldera.com> said:

  Doug> I just noticed a comment was posted on 2001-08-15 to the LSB
  Doug> tracking task on this subject, that a post to fhs-discuss gave
  Doug> the solution to the question of where ia32 vs ia64 libs should
  Doug> be placed.

  Doug> `The /lib directory on x86 and IA64 will always contain the
  Doug> 32bit libraries. IA64 systems should put their libraries in
  Doug> /lib64.' "This way we don't need any special install hooks in
  Doug> the system, installer, and package. It's all hardcoded."

  Doug> The description above are a paraphrase and direct quote from
  Doug> the post to LSB task number 32642 that was used to track what
  Doug> should be done for LSB compatibility.

And we already have discussed this option on the ia64 lists a long
time ago and we rejected it due to source compatibility issues.  /lib
and /usr/lib must contain the native libraries, period.

	--david

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Dugger's]

I don't normally send out agreement messages but this time I have to.  As
David said we've debated this many times in the past and the answer is
always the same.  This is an IA64 system and therefore `/lib', `/usr/lib',
`/bin',
`/sbin' and so on all contain IA64 files.  The IA32 files go elsewhere and
we
work around the issues that this creates.  Specifically where the IA32
objects
go doesn't concern me too much but I adamantly agree that they go elsewhere.
--
Don Dugger
ddugger@qwest.net
----- Original Message -----
From: "David Mosberger" <davidm@hpl.hp.com>
To: <dbb@caldera.com>
Cc: "Ulrich Drepper" <drepper@cygnus.com>; <linux-ia64@linuxia64.org>
Sent: Friday, September 14, 2001 9:51 AM
Subject: Re: [Linux-ia64] Location of absolute IA32 shared objects.


> >>>>> On Fri, 14 Sep 2001 08:30:22 -0600, Doug Beattie <dbb@caldera.com>
said:
>
>   Doug> I just noticed a comment was posted on 2001-08-15 to the LSB
>   Doug> tracking task on this subject, that a post to fhs-discuss gave
>   Doug> the solution to the question of where ia32 vs ia64 libs should
>   Doug> be placed.
>
>   Doug> `The /lib directory on x86 and IA64 will always contain the
>   Doug> 32bit libraries. IA64 systems should put their libraries in
>   Doug> /lib64.' "This way we don't need any special install hooks in
>   Doug> the system, installer, and package. It's all hardcoded."
>
>   Doug> The description above are a paraphrase and direct quote from
>   Doug> the post to LSB task number 32642 that was used to track what
>   Doug> should be done for LSB compatibility.
>
> And we already have discussed this option on the ia64 lists a long
> time ago and we rejected it due to source compatibility issues.  /lib
> and /usr/lib must contain the native libraries, period.
>
> --david
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[David Mosberger]

>>>>> On Mon, 10 Sep 2001 21:11:46 -0700, David Mosberger <davidm@hpl.hp.com> said:

>>>>> On Wed, 5 Sep 2001 22:47:17 +0200, Christoph Hellwig <hch@ns.caldera.de> said:
  Christoph> Please take a look at include/asm-*/namei.h - we can
  Christoph> define an emulation prefix for Linux/i386
  Christoph> (e.g. /emul/linux32) and all lookups will be tried there
  Christoph> before falling back to the native FS, This appropeach is
  Christoph> already used by the MIPS and SPARC ports and by linux-abi
  Christoph> for i386.

  David> I don't particularly like changing filenames underneath the
  David> user, but as far as I can see, it's the most systematic way
  David> to fix absolute naming issues.  Unless someone has serious
  David> objections to this, I'll make this change.  As far as I can
  David> see, neither LSB nor FHS address the issue of where to place
  David> emulation files, so I'll propose a prefix of
  David> "/emul/ia32-linux/" as a starter.  Any objections?

Getting this to work required a little more than just changing
namei.h, but nothing difficult.  In any case, I have this tested now
and it does the job.  In case you're not familiar with how the
emulation prefix works: for any IA-32 binary, absolute filename
lookups will now start in /emul/ia32-linux/.  If the desired file is
found there, it will be used and otherwise the kernel will try to open
the same filename without the prefix.

It seems to me it would make sense if the distributors would retire
using /usr/i386-*-linux and switch over to /emul/ia32-linux instead.
Also, it should be possible to move /lib/ld-linux.so* etc. to
/emul/ia32-linux/lib.

	--david

Re: [Linux-ia64] Location of absolute IA32 shared objects.

[Jes Sorensen]

>>>>> "Doug" = Doug Beattie <dbb@caldera.com> writes:

Doug> I just noticed a comment was posted on 2001-08-15 to the LSB
Doug> tracking task on this subject, that a post to fhs-discuss gave
Doug> the solution to the question of where ia32 vs ia64 libs should
Doug> be placed.

Doug> `The /lib directory on x86 and IA64 will always contain the
Doug> 32bit libraries. IA64 systems should put their libraries in
Doug> /lib64.' "This way we don't need any special install hooks in
Doug> the system, installer, and package. It's all hardcoded."

It's extremely nice of the FHS people to make such decisions without
consulting with the people who actually deals with the architecture in
question. Fortunately their silly decision wont have any effect here,
native libraries go in /lib and /usr/lib. They will have to change the
spec.

Keep in mind that ia32 binaries are a compatibility issue not a 'this
is what we recommend you use forever on this system' type of thing.

Jes