Spilt libperl from perl

[Hans de Goede]

Jeremy Katz wrote:
> On Mon, 2007-04-23 at 22:21 +0200, Hans de Goede wrote:
>> Bill Nottingham wrote:
>>> 2) Development - developing i386 apps on a x86_64 box. Or ppc64 apps anywhere.
>>>
>>> #2 has historically been a problem that multlib solved. In a fully open
>>> Fedora world, it can be solved with mock (assuming we throw up a full
>>> ppc64 tree somewhere).
>>>
>> Actually 2 is a problem that multilib doesn't solve, I've written some scripts 
>> / hacks to be able to build i386 on x86_64 without using mock because I have a 
>> slow link and thus mock used to take eons, now it only takes ages (--autocache 
>> rules!). However these scripts were a big hack, and even with this big hack 
>> things didn't always work properly. Using mock is the only sane way to build 
>> i386 packages on an x86_64 install.
> 
> That's only true if the world revolves around developing packages.  If
> I'm a software developer writing and testing software, it works quite
> nicely.  I have a checkout of anaconda, I run make and it builds for
> x86_64.  If I have a need to test something or see something on i386, I
> just have to ensure that -m32 is in my CFLAGS/LDFLAGS and can use the
> same environment.  And then copy over the shared object into where I'm
> testing or whatever happens to be needed for that case.
> 
> And the above holds true for a *LOT* of software.  If I'm using
> something with pkg-config, I have to also set its appropriate
> environment variable.  And similarly pass the right args to configure
> for autofoolery.  
> 

Have you actually tried this? I agree that if you've software with a simple 
straight forward makefile then it might work, and thus that it could work for 
software you develop yourself. But it doesn't hold true for a *LOT* of software.

There are just to many hacks in Makefile's / configure / scons / whatever build 
files which break. If you want reproducable results using an i386 chroot really 
seems to be the best way to develop i386 on x86_64.

> Building packages is an entirely different ball of wax.  And part of the
> problem there is more bugs in the implementation with RPM than anything
> else.[1]
> 

Actually when trying this rpm was the least of my problems, its funky things 
like checking for the existence of /lib64 and then always install the libs 
there, etc, etc.

Regards,

Hans