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: bertrand
Subject: Re: GNUstep + libobjc2 and powerpc ( was "libobjc2 on powerpc")
Date: Thu, 22 Mar 2018 12:58:42 +0100

Thanks all of you ! Not a success yet, but there is some progress. Base
still doesn't configure and I wonder if my libobjc2 is the culprit (see
at the end).
.

Le jeudi 22 mars 2018 à 10:37 +0000, Richard Frith-Macdonald a écrit :
> 
> > 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 just tried to rebuilding evrything from the start, with gnustep-make
only once and had to manually put libobjc in GNUstem/Local... to avoid
some ld failure when configure base.
> > I've even added --enable-install-ld-so-conf to gnustep-make configure.
> 
> That should be harmless.
> 

I didn't uses this option tis time. It had the GNUstep paths
in /etc/ld.so.conf.d/ so I fault it would cure my linker error.


> > 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'
> 
I've removed the OBJCFLAGS and used your configure option.

> 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.  
> 
> 
Josh had it !
I've downloaded debian source for libdispatch, rebuilt without any
option and installed it.
No more R_PPC_24 relocation in the .so file so it's now correct. This
error doesn't appear anymore in base configuration.

But I've got another error now : a segfault in conftest

In file included from conftest.c:108:
In file included from ././config/config.objc.m:2:
././config/objc-common.g:54:3: warning: assignment to Objective-C's isa
is deprecated in favor of object_setClass()
[-Wdeprecated-objc-isa-usage]
  obj->isa = self;
  ^  ~~~~~~~
  object_setClass( , )
././config/objc-common.g:47:5: note: instance variable is declared here
 id isa;
    ^
1 warning generated.
configure:7834: $? = 0
configure:7834: ./conftest
./configure: line 1875:  3111 Segmentation fault      ./conftest
$ac_exeext
configure:7834: $? = 139
configure: program exited with status 139
configure: failed program was:

Complete config.log attached

Thanks.


Attachment: config.log
Description: Text Data


reply via email to

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