[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Special builds of GNUstep [Was: Re: NSSavePanel fragile ABI - do we
From: |
Ivan Vučica |
Subject: |
Re: Special builds of GNUstep [Was: Re: NSSavePanel fragile ABI - do we care?] |
Date: |
Tue, 13 Aug 2013 16:51:46 +0200 |
On Monday, August 12, 2013, Luboš Doležel wrote:
On 08/12/2013 06:36 PM, Fred Kiefer wrote:
>> BTW, GNUstep's build system is driving me crazy. I do ./configure
>> > --prefix=/usr (as ./configure --help advises) and it still installs into
>> > /usr/local.
> You should select the prefix when configuring GNUstep make. From there
> it should work.
And what do I do to build a 32-bit version on a 64-bit system with libs
installed into /usr/lib32? The configure script drops everything I pass
to it, which doesn't seem right. At least ./configure --help is then
quite confusing.
I'm trying to write a Gentoo ebuild to compile gnustep-base+gui for
64-bit and 32-bit at the same time. GNUstep has been very resistant so far.
If you can't do it any other way, try looking at gnustep-make and its subfolder "FilesystemLayouts". Create a new layout in that folder, then pass it to --with-layout.
The usual way is to add -m32 into CFLAGS, but that is dropped. An
alternative is to specify CC="clang -m32", but that is rejected:
configure: error: You are running configure with the compiler (clang
-m32) set to a different value from that used by gnustep-make (clang).
Please run configure again with your environment set to match your
gnustep-make
But it doesn't seem feasible to somehow have two separate gnustep-makes
in the system.
You seem to be passing this flag solely to a library and not to gnustep-make.
Why not:
cd gnustep/core/make
CC="clang -m32" ./configure $OTHER_FLAGS_YOU_WANT_HERE && make && sudo -E make install
cd -
cd gnustep/core/base
CC="clang -m32" ./configure $OTHER_FLAGS_YOU_WANT_HERE && make && sudo -E make install
cd -
... etc ...
Alternatively, export CC="clang -m32" before EVERYTHING.
Note, I think once I deleted GNUstep manually, but something was picking up an old, stray GNUstep configuration file, which is (I think) installed in /etc/GNUstep. If, after you re-build everything (especially gnustep-make) using the above commands, you still have issues -- then you may want to wipe as much GNUstep from the system as possible (including any stray configuration files) before proceeding.
I recommend playing around in a VM with an abundant use of snapshots, or on an hourly charged VPS where you can get a clean machine up within seconds. :-)
--
- NSSavePanel fragile ABI - do we care?, Luboš Doležel, 2013/08/10
- Re: NSSavePanel fragile ABI - do we care?, Ivan Vučica, 2013/08/10
- Re: NSSavePanel fragile ABI - do we care?, Gregory Casamento, 2013/08/10
- Re: NSSavePanel fragile ABI - do we care?, Fred Kiefer, 2013/08/11
- Re: NSSavePanel fragile ABI - do we care?, Luboš Doležel, 2013/08/11
- Re: NSSavePanel fragile ABI - do we care?, Fred Kiefer, 2013/08/11
- Re: NSSavePanel fragile ABI - do we care?, Luboš Doležel, 2013/08/12
- Re: NSSavePanel fragile ABI - do we care?, Fred Kiefer, 2013/08/12
- Special builds of GNUstep [Was: Re: NSSavePanel fragile ABI - do we care?], Luboš Doležel, 2013/08/12
- Re: Special builds of GNUstep [Was: Re: NSSavePanel fragile ABI - do we care?],
Ivan Vučica <=