FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 04-17-2008, 05:41 PM
Rex Dieter
 
Default 32- and 64-bit softwares living together

Sérgio Durigan Júnior wrote:

Hello folks,

I would like to know if there are any efforts to make both 32- and
64-bit versions of the same package "live" together in a system.


32/64 bit versions of any/all packages? No.

But if the pkg's in question satisfy fedora's notion/definition of
multilib (which is complicated in itself), yes.


Clear as mud?

-- Rex

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-17-2008, 06:27 PM
Rex Dieter
 
Default 32- and 64-bit softwares living together

Sérgio Durigan Júnior wrote:


Well, what happens is that in some archs (specifically PowerPC in our
case) it's very common to have a biarch environment (i.e., 64-bit kernel
and mixed 32/64-bit userspace), so it's not a strange thing to have both
versions of some software installed in the system.


Right. If there are 32/64 packages available, and they don't properly
install/run, then that's generally considered a bug (that should be fixed).


-- Rex

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-18-2008, 03:19 AM
Ralf Corsepius
 
Default 32- and 64-bit softwares living together

On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
> Sérgio Durigan Júnior wrote:
>
> > Well, what happens is that in some archs (specifically PowerPC in our
> > case) it's very common to have a biarch environment (i.e., 64-bit kernel
> > and mixed 32/64-bit userspace), so it's not a strange thing to have both
> > versions of some software installed in the system.
>
> Right. If there are 32/64 packages available, and they don't properly
> install/run, then that's generally considered a bug (that should be fixed).

Here is one:

# rpm -q --qf "%{name}.%{arch}
" -f /lib/libgcc_s.so.1
libgcc.i386

# rpm -q --qf "%{name}.%{arch}
" -f
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
gcc.x86_64

# ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
-> /lib/libgcc_s.so.1

i.e. an x86_64 package depending on an i386 package.


Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.

I am trying to package a package which needs to build and run some bits
"-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64)
environment, but I haven't managed to get this working in mock.


Ralf




--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-18-2008, 03:33 AM
seth vidal
 
Default 32- and 64-bit softwares living together

On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote:
> On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
> > Sérgio Durigan Júnior wrote:
> >
> > > Well, what happens is that in some archs (specifically PowerPC in our
> > > case) it's very common to have a biarch environment (i.e., 64-bit kernel
> > > and mixed 32/64-bit userspace), so it's not a strange thing to have both
> > > versions of some software installed in the system.
> >
> > Right. If there are 32/64 packages available, and they don't properly
> > install/run, then that's generally considered a bug (that should be fixed).
>
> Here is one:
>
> # rpm -q --qf "%{name}.%{arch}
" -f /lib/libgcc_s.so.1
> libgcc.i386
>
> # rpm -q --qf "%{name}.%{arch}
" -f
> /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> gcc.x86_64
>
> # ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> -> /lib/libgcc_s.so.1
>
> i.e. an x86_64 package depending on an i386 package.
>
>
> Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.
>
> I am trying to package a package which needs to build and run some bits
> "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64)
> environment, but I haven't managed to get this working in mock.
>
>

try using yum 3.2.14 from rawhide with mock and remove the silly exclude
that's in mock currently for x86_64 builds.

I know mdomsch and jkeating have tested it and had good success with
multilib_policy=best

-sv


--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 04-18-2008, 04:04 AM
Ralf Corsepius
 
Default 32- and 64-bit softwares living together

On Thu, 2008-04-17 at 23:33 -0400, seth vidal wrote:
> On Fri, 2008-04-18 at 05:19 +0200, Ralf Corsepius wrote:
> > On Thu, 2008-04-17 at 13:27 -0500, Rex Dieter wrote:
> > > Sérgio Durigan Júnior wrote:
> > >
> > > > Well, what happens is that in some archs (specifically PowerPC in our
> > > > case) it's very common to have a biarch environment (i.e., 64-bit kernel
> > > > and mixed 32/64-bit userspace), so it's not a strange thing to have both
> > > > versions of some software installed in the system.
> > >
> > > Right. If there are 32/64 packages available, and they don't properly
> > > install/run, then that's generally considered a bug (that should be fixed).
> >
> > Here is one:
> >
> > # rpm -q --qf "%{name}.%{arch}
" -f /lib/libgcc_s.so.1
> > libgcc.i386
> >
> > # rpm -q --qf "%{name}.%{arch}
" -f
> > /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> > gcc.x86_64
> >
> > # ls -l /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> > /usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
> > -> /lib/libgcc_s.so.1
> >
> > i.e. an x86_64 package depending on an i386 package.
> >
> >
> > Now try to install /lib/libgcc_s.so.1 in an x86_64 mock chroot.
> >
> > I am trying to package a package which needs to build and run some bits
> > "-m32 compiled on x86_64". Works in a normal (multilib'ed x86_64)
> > environment, but I haven't managed to get this working in mock.
> >
> >
>
> try using yum 3.2.14 from rawhide with mock and remove the silly exclude
> that's in mock currently for x86_64 builds.
OK, this will likely resolve the "mock" part of this issue (yet
untested), but leaves other parts unclear:

Which rpm "arch" and which package does the
/usr/lib/gcc/x86_64-redhat-linux/4.3.0/32/libgcc_s.so
-> /lib/libgcc_s.so.1 symlink belong to?

ATM, it is part of gcc.x86_86 and is a dangling symlink in "pure
basearch" installs.

Should it (or even the whole m32 subdir) be part of an *.i386 package?

Or, conversely should /lib/libgcc_s.so.1 (clearly i386'ed) be part of a
"multilib'ed" gcc.x86_64 package or libgcc.x86_64 package?

I don't know.

Ralf





--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 

Thread Tools




All times are GMT. The time now is 10:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org