[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Spilt libperl from perl



On Mon, 2007-04-23 at 22:41 +0200, Hans de Goede wrote:
> 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.

I've tried it on a fair bit of stuff.  And while there are cases where
things break (at which point, they're usually pretty straight-forward to
fix and send patches), things _are_ getting quite a bit better.

Jeremy


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]