Re: How to package code compiled with 'gcc -m32'?

Toshio Kuratomi wrote:
> Orion Poplawski wrote:
>> Richard W.M. Jones wrote:
>>> I've expressed that with a file dependency which breaks Fedora
>>> packaging guidelines:
>>>
>>>   BuildRequires:  /usr/include/gnu/stubs-32.h
> Note: The particular Guideline is a SHOULD rather than MUST.  It also
> applies to Requires, rather than BuildRequires, although that might not
> be so obvious.  The intention as stated in the Guideline is to save
> end-user time by allowing the depsolver to skip downloading of the large
> filelists metadata file.

I also had the impression (I may be wrong) that this applied more to 
runtime dependencies than build-time dependencies, for which downloading 
of the file lists is less of an issue.

Paul.

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: How to package code compiled with 'gcc -m32'?

On Tue, 2008-10-07 at 17:56 +0100, Richard W.M. Jones wrote:
> I guess if we ExcludeArch we'll still be OK because x86-64 users will
> be able to install and use the i386 version?

Not without having to hardcode this package as "multilib" to make it
show up in the x86_64 repo.  This is something we really really really
don't like doing, as hardcoded crud like this tends to break over time.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: How to package code compiled with 'gcc -m32'?

Richard W.M. Jones wrote:
> On Tue, Oct 07, 2008 at 11:12:09AM -0400, Jeremy Katz wrote:
>> On Tue, 2008-10-07 at 14:35 +0100, Richard W.M. Jones wrote:
>>> I've got a nasty program I'm trying to package for Fedora.  To cut a
>>> very long story short, this C/C++ mixed program started out on Windows
>>> and makes lots of 32 bit assumptions.  So it's compiled with 'gcc -m32'.
>>>
>>> Expressing the build requirements so it can build on a 64 bit platform
>>> is proving troublesome.  (It builds fine on i386).
>> In general, for these situations the right answer is to ExcludeArch and
>> file the appropriate tracking bugs rather than trying to do 32-bit
>> builds on a 64-bit arch.  The latter is only done in a few special cases
>> (bootloaders mainly) which don't have any external deps
> 
> The issues is actually weirder / more complicated than I thought.
> (But hey, Windows software, what do you expect 
> 
> It turns out that it's not just built for 32 bit because of the
> general hideousness of the code, but because it builds Windows 32 bit
> plugins.  Somehow -- and I've no idea how it does this -- the Windows
> plugins get loaded into the native Fedora binary at runtime.  Even
> though the main binary is Fedora native, it still has to be built as
> 32 bit to achieve this minor miracle.
> 
> The package is NSIS, in case you were wondering ...
> 
> http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=d9257c5046c7e63b8c00d01528031f14cf6fc319;path=/nsis/
> 
> http://www.annexia.org/tmp/mingw/fedora-9/x86_64/RPMS/mingw32-nsis-2.39-3.fc9.x86_64.rpm
> 

Re: How to package code compiled with 'gcc -m32'?

Richard W.M. Jones <rjones <at> redhat.com> writes:
> It turns out that [NSIS is] not just built for 32 bit because of the
> general hideousness of the code, but because it builds Windows 32 bit
> plugins.  Somehow -- and I've no idea how it does this -- the Windows
> plugins get loaded into the native Fedora binary at runtime.

Those plugins don't actually get loaded into the Fedora binary. They get packed 
into the generated installer image.

> Even though the main binary is Fedora native, it still has to be built as
> 32 bit to achieve this minor miracle.

The Debian folks worked hard on making NSIS build as a true 64-bit binary, not 
with -m32, and as far as I know their patches got merged upstream already.

The W32 plugins need to be built with the MinGW cross-compiler of course, not 
the native compiler, so they aren't affected by this problem at all.

I can have a try at making a proper x86_64 package with the plugins actually 
built from source. What I know is that my hack (packaging the binary plugins 
from the prebuilt ZIP and rebuilding makensis from source as 64-bit) worked.

What's clear is that 32-bit binaries on a 64-bit system are not a solution, you 
have to be very special like WINE to get away with this (and even WINE is not 
built with -m32, it's simply copied from the i386 repo by a multilib whitelist 
entry; fake x86_64 packages with 32-bit stuff in it are a bad idea), NSIS has 
really no valid reason to use 32-bit binaries.

        Kevin Kofler