lib64 in fedora glibc

lib64 in fedora glibc

[Aron Griffis]

These snippets from the current fedora glibc.spec look suspicious to
me.. I was under the impression that ia64 would use /lib for 64-bit
and /lib32 for 32-bit (or something like that), but it looks like RH
is preparing to transition to lib64.

Patch4: %{name}-ia64-lib64.patch

%prep:
    %ifarch ia64
    %if "%{_lib}" = "lib64"
    %patch4 -p1
    %endif

%install:
    %ifarch ia64
    %if "%{_lib}" = "lib64"
    # Compatibility symlink
    mkdir -p $RPM_BUILD_ROOT/lib
    ln -sf /%{_lib}/ld-linux-ia64.so.2 $RPM_BUILD_ROOT/lib/ld-linux-ia64.so.2
    %endif
    %endif

%files:
    %ifarch ia64
    %if "%{_lib}" = "lib64"
    %dir /lib
    /lib/ld-linux-ia64.so.2
    %endif
    %endif

%changelog:
    * Thu May 20 2004 Jakub Jelinek <jakub@redhat.com> 2.3.3-29
    - use lib64 instead of lib on ia64 if %%{_lib} is defined to lib64

--
Aron Griffis
hp Linux and Open Source Lab

Re: lib64 in fedora glibc

[David Mosberger]

>>>>> On Fri, 28 May 2004 17:41:05 -0400, Aron Griffis <aron@HP.COM> said:

  Aron> These snippets from the current fedora glibc.spec look suspicious to
  Aron> me.. I was under the impression that ia64 would use /lib for 64-bit
  Aron> and /lib32 for 32-bit (or something like that), but it looks like RH
  Aron> is preparing to transition to lib64.

I'm no Fedora expert but here it says:

  Aron> %changelog:
  Aron> * Thu May 20 2004 Jakub Jelinek <jakub@redhat.com> 2.3.3-29
  Aron> - use lib64 instead of lib on ia64 if %%{_lib} is defined to lib64

So I guess the question is what would make %%{_lib} be defined as lib64.

IMHO, it would be a bad mistake to create such a disruption.

	--david

Re: lib64 in fedora glibc

[Aron Griffis]

David Mosberger wrote:	[Fri May 28 2004, 06:14:54PM EDT]
>   Aron> it looks like RH
>   Aron> is preparing to transition to lib64.
> 
> So I guess the question is what would make %%{_lib} be defined as lib64.

Right, that's why I suggested it appears they're preparing for the
transition.  I guess writing Jakub would be the best way to find
out...

-- 
Aron Griffis
hp Linux and Open Source Lab

Re: lib64 in fedora glibc

[Grant Grundler]

On Fri, May 28, 2004 at 11:33:36PM -0400, Aron Griffis wrote:
> > So I guess the question is what would make %%{_lib} be defined as lib64.
> 
> Right, that's why I suggested it appears they're preparing for the
> transition. 

"the transition" might be necessary to support x86_64.
Ie most of user space is 32-bit (using /lib) but some apps
will run substantially better as native x86_64 binaries.
Moving to lib32 and lib64 makes sense in that environment.

Hypothetically, it shouldn't matter for ia64 if /lib
is an alias for /lib64. Or do I see that wrong?
I thought ia64 already has from /lib32-like thing to
support ia32 binaries but I'm not the tool chain expert.

grant

Re: lib64 in fedora glibc

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Grant Grundler <iod00d@hp.com> writes:

> On Fri, May 28, 2004 at 11:33:36PM -0400, Aron Griffis wrote:
>> > So I guess the question is what would make %%{_lib} be defined as lib64.
>> 
>> Right, that's why I suggested it appears they're preparing for the
>> transition. 
>
> "the transition" might be necessary to support x86_64.
> Ie most of user space is 32-bit (using /lib) but some apps
> will run substantially better as native x86_64 binaries.

Just a clarification: AMD64 [1] has most of user space 64-bit.  Only a
few applications are 32-bit - but this lib/lib64 is the best way to
handle 32-bit packages (no need to change files).

> Moving to lib32 and lib64 makes sense in that environment.

Not lib32, just lib.

Andreas

Footnotes: 
[1]  at least the SUSE distribution but I assume others as well.

-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: lib64 in fedora glibc

[David Mosberger]

>>>>> On Tue, 01 Jun 2004 11:48:56 +0200, Andreas Jaeger <aj@suse.de> said:

  Andreas> Just a clarification: AMD64 [1] has most of user space
  Andreas> 64-bit.  Only a few applications are 32-bit - but this
  Andreas> lib/lib64 is the best way to handle 32-bit packages (no
  Andreas> need to change files).

  >> Moving to lib32 and lib64 makes sense in that environment.

  Andreas> Not lib32, just lib.

That may be a reasonable solution for x86-64 but I don't think it is
for ia64.  What's needed is multi-architecture support, not bi-arch
support.  Let's consider some possible bi-arch setups:

			contents of:

host arch:	/usr/lib	/usr/lib64
----------
x86-64		x86		x86-64
ia64		x86		ia64
ppc64		ppc32		ppc64

So far, so good.  But what if x86-64 emulation support were added to
Intel's IA32EL?  With the bi-arch-logic, that's either not supported
or you'd have to move the ia64-stuff _again_ from /usr/lib64 into some
other place.  Thanks, but no thanks.  Not to mention that trying to
move ia64 libraries from /usr/lib to /usr/lib64 is almost certainly
worse than any ill it could possibly cure.

Even if you didn't in the above scenario, it wouldn't surprise me if
the ppc64 folks also wanted to be able to run x86 binaries.  If so,
the bi-arch approach won't work for them either, because /usr/lib is
already taken by ppc32.

	--david

Re: lib64 in fedora glibc

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 2565 bytes --]

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

>>>>>> On Tue, 01 Jun 2004 11:48:56 +0200, Andreas Jaeger <aj@suse.de> said:
>
>   Andreas> Just a clarification: AMD64 [1] has most of user space
>   Andreas> 64-bit.  Only a few applications are 32-bit - but this
>   Andreas> lib/lib64 is the best way to handle 32-bit packages (no
>   Andreas> need to change files).
>
>   >> Moving to lib32 and lib64 makes sense in that environment.
>
>   Andreas> Not lib32, just lib.
>
> That may be a reasonable solution for x86-64 but I don't think it is
> for ia64.  What's needed is multi-architecture support, not bi-arch
> support.  Let's consider some possible bi-arch setups:
>
> 			contents of:
>
> host arch:	/usr/lib	/usr/lib64
> ----------
> x86-64		x86		x86-64
> ia64		x86		ia64
> ppc64		ppc32		ppc64
>
> So far, so good.  But what if x86-64 emulation support were added to
> Intel's IA32EL?  With the bi-arch-logic, that's either not supported
> or you'd have to move the ia64-stuff _again_ from /usr/lib64 into some
> other place.  Thanks, but no thanks.  Not to mention that trying to
> move ia64 libraries from /usr/lib to /usr/lib64 is almost certainly
> worse than any ill it could possibly cure.
>
> Even if you didn't in the above scenario, it wouldn't surprise me if
> the ppc64 folks also wanted to be able to run x86 binaries.  If so,
> the bi-arch approach won't work for them either, because /usr/lib is
> already taken by ppc32.

We're speaking here about native code - and not emulations.  So, for
ia64 I only see two native codes right now: 64-bit code as it is and
code using 32-bit pointers (don't know how it's called).

And x86 on ppc64 would be an emulation - not the native code - and
would end somewhere else.

Note that what your table says about ppc64 and x86-64 above is correct
- and you can add s390, mips and sparc64 under the same line.  Sparc has
done this for a long time already.

For details see the FHS.  The big advantage on x86-64 [1] with lib and
lib64 is that you can use existing 32-bit x86 rpms and install them -
and they work without changes.

I don't know what Red Hat is doing with x86 and with lib64 - and you
really should ask them for clarification.

Andreas

Footnotes: 
[1]  Note I'm more concerned with x86-64, I'm not advocating here
     anything for ia64.

-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: lib64 in fedora glibc

[David Mosberger]

>>>>> On Fri, 04 Jun 2004 07:08:18 +0200, Andreas Jaeger <aj@suse.de> said:

  Andreas> We're speaking here about native code - and not emulations.
  Andreas> So, for ia64 I only see two native codes right now: 64-bit
  Andreas> code as it is and code using 32-bit pointers (don't know
  Andreas> how it's called).

That'd be ia64/ILP32, which isn't supported on Linux (or Windows,
though it is on HP-UX).

  Andreas> And x86 on ppc64 would be an emulation - not the native code - and
  Andreas> would end somewhere else.

Yep.

  Andreas> Note that what your table says about ppc64 and x86-64 above
  Andreas> is correct - and you can add s390, mips and sparc64 under
  Andreas> the same line.  Sparc has done this for a long time
  Andreas> already.

Yep.

  Andreas> I don't know what Red Hat is doing with x86 and with lib64 - and you
  Andreas> really should ask them for clarification.

Certainly.  I only wished Red Hat would be more
willing/interested/active in discussing such things on public mailing
lists.

  Andreas> Footnotes:
  Andreas> [1]  Note I'm more concerned with x86-64, I'm not advocating here
  Andreas> anything for ia64.

No problem.  I just wanted to make it clear why I think it would be
short-sighted to pub x86 libraries in /usr/lib on ia64.

	--david

Re: lib64 in fedora glibc

[Christoph Hellwig]

On Thu, Jun 03, 2004 at 11:21:00PM -0700, David Mosberger wrote:
> That'd be ia64/ILP32, which isn't supported on Linux (or Windows,
> though it is on HP-UX).

Actually suse had a binfmt_ilp32 for ia64 last time I checked.  No idea
what they actually used it for, though.

Re: lib64 in fedora glibc

[Bill Nottingham]

David Mosberger (davidm@napali.hpl.hp.com) said: 
>   Andreas> I don't know what Red Hat is doing with x86 and with lib64 - and you
>   Andreas> really should ask them for clarification.
> 
> Certainly.  I only wished Red Hat would be more
> willing/interested/active in discussing such things on public mailing
> lists.

Where this came out of was requests from various partners and ISVs
who noticed that their 32-bit apps didn't run right on ia64 with
the /emul/ia32-linux prefix. This is due to some of the fundamental
issues with that arrangement:

- 64-bit processes don't see into that tree because of their personality
  (think: shell scripts)
- the results of readdir() on a directory in /emul/ia32-linux will not
  necessarily match the files you can actually access with open()

The simplest way to solve this, while maintaining compatiblity with
ia32 packages, is to get them on the same filesystem. This is where
the proposal stemmed from, originally.

We can always just live with crappy ia32 (and by extension,
x86-64) support on ia64. :)

Bill

Re: lib64 in fedora glibc

[David Mosberger]

>>>>> On Fri, 4 Jun 2004 15:23:19 -0400, Bill Nottingham <notting@redhat.com> said:

  Bill> Where this came out of was requests from various partners and
  Bill> We can always just live with crappy ia32 (and by extension,
  Bill> x86-64) support on ia64. :)

I don't think "crappy" is acceptable but it doesn't have to be perfect
on ia64, because you 99% of the apps on a typically Linux box will be
ia64-native binaries (I'd imagine the reverse may often be true for
x86-64).

Again, I don't think multi-arch support is ia64-specific, so whatever
can be done to improve this support will help other platforms, too.
I'm guessing that some of the ISV problems have come from the fact
that they tried to install _everything_ into /emul/ia32-linux?  That
is probably not the best approach.  For self-contained applications,
just installing in /opt or some place like that should work just fine
(and in my experience it does).  /emul/ia32-linux should probably be
reserved for use for files that are known or very likely to collide
with ia64 files of the same name (such as the gtk engine shared
libraries).

As for running shell scripts: isn't there a linux32 command that takes
care of that?

	--david

Re: lib64 in fedora glibc

[Bill Nottingham]

David Mosberger (davidm@napali.hpl.hp.com) said: 
>   Bill> Where this came out of was requests from various partners and
>   Bill> We can always just live with crappy ia32 (and by extension,
>   Bill> x86-64) support on ia64. :)
> 
> I don't think "crappy" is acceptable but it doesn't have to be perfect
> on ia64, because you 99% of the apps on a typically Linux box will be
> ia64-native binaries (I'd imagine the reverse may often be true for
> x86-64).

Actually, most x86-64 stuff is native too. Where this normally
hits with ISVs is their middleware apps. Apparently, ISVs are
averse to rebuilding their custom-changed Apache or databases,
and want to just run the x86 binaries.

> Again, I don't think multi-arch support is ia64-specific, so whatever
> can be done to improve this support will help other platforms, too.
> I'm guessing that some of the ISV problems have come from the fact
> that they tried to install _everything_ into /emul/ia32-linux?  That
> is probably not the best approach.  For self-contained applications,
> just installing in /opt or some place like that should work just fine
> (and in my experience it does).  /emul/ia32-linux should probably be
> reserved for use for files that are known or very likely to collide
> with ia64 files of the same name (such as the gtk engine shared
> libraries).

Only doing it for some files isn't really practical from a distribution
standpoint; keeping tables of what 32-bit stuff goes in 'X', what
32-bit stuff goes in 'Y', and what 32-bit stuff goes in 'Z' doesn't
scale.

> As for running shell scripts: isn't there a linux32 command that takes
> care of that?

Assuming that you know the shell script wants to use ia32 apps?

Bill

Re: lib64 in fedora glibc

[David Mosberger]

>>>>> On Fri, 4 Jun 2004 16:21:18 -0400, Bill Nottingham <notting@redhat.com> said:

  Bill> Only doing it for some files isn't really practical from a
  Bill> distribution standpoint; keeping tables of what 32-bit stuff
  Bill> goes in 'X', what 32-bit stuff goes in 'Y', and what 32-bit
  Bill> stuff goes in 'Z' doesn't scale.

I wasn't advocating a particular solution.  All I'm saying is that
reasonably good multi-arch support would be useful for a number of
platforms.

	--david

RE: lib64 in fedora glibc

[Saxena, Sunil]

on Friday, June 04, 2004 1:21 PM, Bill Nottingham wrote :
> Actually, most x86-64 stuff is native too. Where this normally
> hits with ISVs is their middleware apps. Apparently, ISVs are
> averse to rebuilding their custom-changed Apache or databases,
> and want to just run the x86 binaries.
> 
We did not receive any complaints from any ISVs for running x86 binaries
today.
I agree that they may have gone through some irritation to get it to
work.  I 
would love know details of the cases where you saw this did not work.  I
can 
give you one example of installation where it runs /bin/arch and invokes
the 
compiler to link the objects.  This runs fine in the /emul/ia32-linux
where you have 
all the binaries and utilities in the right place.  I assume that this
can be made to work with some personality utility that would tell the
installer that
it is running on x86 box.  Is that possible?

> Only doing it for some files isn't really practical from a
distribution
> standpoint; keeping tables of what 32-bit stuff goes in 'X', what
> 32-bit stuff goes in 'Y', and what 32-bit stuff goes in 'Z' doesn't
> scale.
> 
I think the challenge is how to support more than two architectures and
multiple data models in a single distribution.  Since ia64 does not have
a 
32-bit native model and 64-bit model is the default model, the /lib
should 
be the default. One could symbolically link /lib to /lib64. Other 
multi-architectures should be put in other identifiable directories..

Re: lib64 in fedora glibc

[Bill Nottingham]

Saxena, Sunil (sunil.saxena@intel.com) said: 
> on Friday, June 04, 2004 1:21 PM, Bill Nottingham wrote :
> > Actually, most x86-64 stuff is native too. Where this normally
> > hits with ISVs is their middleware apps. Apparently, ISVs are
> > averse to rebuilding their custom-changed Apache or databases,
> > and want to just run the x86 binaries.
> > 
> We did not receive any complaints from any ISVs for running x86 binaries
> today.
> I agree that they may have gone through some irritation to get it to
> work.  I 
> would love know details of the cases where you saw this did not work.

Pretty simple... install all the x86 RPMs required to run x86
OpenOfffice.... it will not start, due to it being unable to
find its library directories.

Bill

Re: lib64 in fedora glibc

[Andreas Schwab]

Bill Nottingham <notting@redhat.com> writes:

> Pretty simple... install all the x86 RPMs required to run x86
> OpenOfffice.... it will not start, due to it being unable to
> find its library directories.

Works for me.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: lib64 in fedora glibc

[Bill Nottingham]

Andreas Schwab (schwab@suse.de) said: 
> > Pretty simple... install all the x86 RPMs required to run x86
> > OpenOfffice.... it will not start, due to it being unable to
> > find its library directories.
> 
> Works for me.

In what manner are you installing them? Are you running in a
chroot?

Bill

Re: lib64 in fedora glibc

[Andreas Schwab]

Bill Nottingham <notting@redhat.com> writes:

> Andreas Schwab (schwab@suse.de) said: 
>> > Pretty simple... install all the x86 RPMs required to run x86
>> > OpenOfffice.... it will not start, due to it being unable to
>> > find its library directories.
>> 
>> Works for me.
>
> In what manner are you installing them?

Note sure, I didn't do that myself.  I just did a quick check of our
company wide installation, since I have no use for OOo myself.

> Are you running in a chroot?

No.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: lib64 in fedora glibc

[Bill Nottingham]

Andreas Schwab (schwab@suse.de) said: 
> >> > Pretty simple... install all the x86 RPMs required to run x86
> >> > OpenOfffice.... it will not start, due to it being unable to
> >> > find its library directories.
> >> 
> >> Works for me.
> >
> > In what manner are you installing them?
> 
> Note sure, I didn't do that myself.  I just did a quick check of our
> company wide installation, since I have no use for OOo myself.

Which doesn't tell us much. :)

Bill