discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep + libobjc2 and powerpc ( was "libobjc2 on powerpc")


From: Richard Frith-Macdonald
Subject: Re: GNUstep + libobjc2 and powerpc ( was "libobjc2 on powerpc")
Date: Thu, 22 Mar 2018 10:37:07 +0000


> On 22 Mar 2018, at 09:29, bertrand <address@hidden> wrote:
> 
> - building make twice or only once after libobjc2

Just to be clear ... building gnustep-make twice is just a simple workaround 
for libobjc2 being installed in the wrong place (so it wouldn't be found and an 
old runtime would be found/used later) ... the initial build of gnustep-make is 
done to define *where* you want things installed (in your case 
--with-layout=gnustep) and then libobjc can use information from the 
gnustep-make installation to install itself in the right place.  If you want 
libobjc to live outside your gnustep installation, that's fine but you will 
then need to tell gnustep where to find it (using appropriate environment 
variables) unless you put it in the default location on your system (eg /usr).

> - installing libobjc2 in /usr , /usr/local, or even
> in /usr/GNUstep/Local/Library/Libraries/ (I use GNUstep layout) by hand
> - building without gcc's gobjc-4.9.deb and gobjc++-4.9.deb (I thought
> they weren't mandatory) or with them.

Manually putting libobc2 in the correct place is a perfectly fine option 
(installing gnustep-make first just removes the chance of making a mistake 
putting things in place manually).

> I've even added --enable-install-ld-so-conf to gnustep-make configure.

That should be harmless.

> My configure options for make are : 
> 
> ./configure --enable-debug-by-default --with-layout=gnustep
> -enable-objc-nonfragile-abi -enable-objc-arc --enable-install-ld-so-conf

You shouldn't be using -enable-objc-nonfragile-abi -enable-objc-arc unless you 
are sure you want to override normal behavior and know exactly wehat you are 
doing.  Rather, if you want to use new features yoiu should be configuring the 
system to use the new runtime (and hence the compiler options associated with 
it).  That means using -with-library-combo=ng-gnu-gnu

> and I had set OBJCFLAGS="-fblocks -fobjc-runtime=gnustep-1.8.1" before
> the last install of make and run ldconfig just before configuring base.

Also not necessary (and perhaps not helpful).
Basically, if you attempt to use new ObjC features without using the new 
library combo, things may go wrong, and if you use the new library combo you 
should not need to specify any of those old options for enabling/disabling 
runtime related compiler features.
I would suggest './configure --enable-debug-by-default --with-layout=gnustep  
-with-library-combo=ng-gnu-gnu'

All that being said ... I don't actually think any of the configure options you 
aree using is actually the cause of your current problem (see below):

> Each time, the configure step of base fails with the well-known and
> infamous:
> 
>> checking whether objc really works... no
>> I don't seem to be able to use your Objective-C compiler to produce
>> working binaries!  Please check your Objective-C compiler installation.
>> If you are using gcc-3.x make sure that your compiler's libgcc_s and libobjc
>> can be found by the dynamic linker - usually that requires you to play
>> with LD_LIBRARY_PATH or /etc/ld.so.conf.
>> Please refer to your compiler installation instructions for more help.
>> configure: error: The Objective-C compiler does not work or is not installed 
>> properly.

The line in the config file that's important is the error immediately before it 
tests for a working objc:

./conftest: error while loading shared libraries: /usr/lib/libdispatch.so.0: 
R_PPC_REL24 relocation at 0x0fc83f40 for symbol `gettimeofday' out of range

So the problem is with libdispatch.  I'm not the sort of linker/compiler guru 
who can tell you why there's a relocation issue or what to do about it though.  
Possibly there are compiler flags (that you could put in CFLAGS before 
configuring) to deal with it, or possibly it's something wrong with the way 
libdispath itself was built.  





reply via email to

[Prev in Thread] Current Thread [Next in Thread]