> On 22 Mar 2018, at 09:29, bertrand <[email protected]> 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. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
