Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 465668 - gnustep-base/gnustep-base-1.24.6-r1 with gnustep-base:libobjc2-1.7 - configure: error: The Objective-C compiler does not work or is not installed properly. (/usr/lib/libobjc.so.4 symlink missing)
Summary: gnustep-base/gnustep-base-1.24.6-r1 with gnustep-base:libobjc2-1.7 - configur...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Gentoo Gnustep project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-12 10:43 UTC by adr
Modified: 2015-05-20 11:26 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info '=gnustep-base/gnustep-base-1.24.3 (emerge.info,5.00 KB, text/plain)
2013-04-12 10:45 UTC, adr
Details
build log (20130412-070043.log,10.96 KB, text/plain)
2013-04-12 10:45 UTC, adr
Details
emerge -pqv '=gnustep-base/gnustep-base-1.24.3' (emerge.pqv,94 bytes, text/plain)
2013-04-12 10:46 UTC, adr
Details
work/gnustep-base-1.24.3/config.log (config.log,83.79 KB, text/plain)
2013-04-12 10:47 UTC, adr
Details
emerge --info (emerge.info,4.49 KB, application/x-info)
2014-07-20 06:38 UTC, adr
Details
emerge --info '=gnustep-base/gnustep-base-1.24.6-r1' (emerge.info.gnustep-base-1.24.6-r1,4.93 KB, text/plain)
2014-07-20 07:46 UTC, adr
Details
emerge -pqv '=gnustep-base/gnustep-base-1.24.6-r1' (emerge.pqv.gnustep-base-1.24.6-r1,97 bytes, text/plain)
2014-07-20 07:47 UTC, adr
Details
Build log (without /usr/lib/libobjc.so.4 symlink) (build.log,11.20 KB, text/plain)
2014-07-20 07:51 UTC, adr
Details
Config log (without /usr/lib/libobjc.so.4 symlink) (config.log,84.66 KB, text/plain)
2014-07-20 07:52 UTC, adr
Details
/var/db/pkg/gnustep-base/libobjc2-1.7/CONTENTS (CONTENTS,1.48 KB, text/plain)
2014-07-20 07:54 UTC, adr
Details
emerge -pqv @gnustep (emerge.pqv.@gnustep,2.02 KB, text/plain)
2014-07-22 09:36 UTC, adr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description adr 2013-04-12 10:43:25 UTC
After enabling the "libobjc2" USE flag on gnustep-base/gnustep-make-2.6.4, "emerge -uDN @world" and running "gnustep-updater -l", the first packet to rebuild (gnustep-base/gnustep-base-1.24.3) fails.

...
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. ...

Reproducible: Always




Packages that compile with GCC (currently sys-devel/gcc-4.6.3) still emerge fine.
Comment 1 adr 2013-04-12 10:45:05 UTC
Created attachment 345360 [details]
emerge --info '=gnustep-base/gnustep-base-1.24.3
Comment 2 adr 2013-04-12 10:45:50 UTC
Created attachment 345362 [details]
build log
Comment 3 adr 2013-04-12 10:46:33 UTC
Created attachment 345364 [details]
emerge -pqv '=gnustep-base/gnustep-base-1.24.3'
Comment 4 adr 2013-04-12 10:47:52 UTC
Created attachment 345366 [details]
work/gnustep-base-1.24.3/config.log
Comment 5 adr 2013-04-14 08:14:42 UTC
Enabling the "threads" USE flag on boehm-gc (I'm using dev-libs/boehm-gc-7.2d) let it pass the config script test. It was off by default. So, that seems to be the solution or workaround. Maybe it has to be enforced in the ebuild.

Now, I run into another build error, but it seems to be unrelated to threads, and current bug report. I'll look into it, and file another report. Here's a preview of the error message:

...
In file included from GCObject.m:35:
In file included from ../../Headers/Foundation/NSThread.h:35:
[1m../../Headers/Foundation/NSException.h:44:2: [0m[0;1;31merror: [0m[1m"There are two separate exception handling mechanisms available
      ... one based on the standard setjmp() function (which does not require special compiler support), and one
      'native' version where the compiler manages the exception handling. If you try to use both in the same
      executable, exception handlers will not work... which can be pretty disastrous. This error is telling you that
      the gnustep-base library was built using one formIn file included from  of exception handling, but that the gnustep-make package you
      are using is building code to use the other form of exception handling ... with the consequence that exception
      handling would be broken in the program you are building. So, somehow your gnustep-base and gnustep-make package
      are incompatible, and you need to replace one of them with a version configured to match the other."[0m
#error "There are two separate exception handling mechanisms available ... one based on the standard setjmp()...
[0;1;32m ^
[0m[1m../../Headers/Foundation/NSException.h:48:2: [0m[0;1;31merror: [0m[1m"gnustep-base is configured to use 'traditional' exceptions, but
      you are building for 'native' exceptions."[0m
#error  "gnustep-base is configured to use 'traditional' exceptions, but you are building for 'native' exceptions."
[0;1;32m ^
[0mGSObjCRuntime.m:39:
[1m../../Headers/Foundation/NSException.h:44:2: [0m[0;1;31merror: [0m[1m"There are two separate exception handling mechanisms available
      ... one based on the standard setjmp() function (which does not require special compiler support), and one
      'native' version where the compiler manages the exception handling. If you try to use both in the same
      executable, exception handlers will not work... which can be pretty disastrous. This error is telling you that
      the gnustep-base library was built using one form of exception handling, but that the gnustep-make package you
      are using is building code to use the other form of exception handling ... with the consequence that exception
      handling would be broken in the program you are building. So, somehow your gnustep-base and gnustep-make package
      are incompatible, and you need to replace one of them with a version configured to match the other."[0m
#error "There are two separate exception handling mechanisms available ... one based on the standard setjmp()...
[0;1;32m ^
[0m[1m../../Headers/Foundation/NSException.h:48:2: [0m[0;1;31merror: [0m[1m"gnustep-base is configured to use 'traditional' exceptions, but
      you are building for 'native' exceptions."[0m
#error  "gnustep-base is configured to use 'traditional' exceptions, but you are building for 'native' exceptions."
[0;1;32m ^
[0m2 errors generated.
make[4]: *** [obj/Additions.obj/GCObject.m.o] Error 1
make[4]: *** Waiting for unfinished jobs....
2 errors generated.
make[4]: *** [obj/Additions.obj/GSObjCRuntime.m.o] Error 1
make[3]: *** [internal-subproject-all_] Error 2
make[2]: *** [Additions.all.subproject.variables] Error 2
make[2]: Leaving directory `/var/portage/gnustep-base/gnustep-base-1.24.3/work/gnustep-base-1.24.3/Source/Additions'
make[1]: *** [internal-all] Error 2
make[1]: Leaving directory `/var/portage/gnustep-base/gnustep-base-1.24.3/work/gnustep-base-1.24.3/Source'
make: *** [internal-all] Error 2
 [31;01m*[0m ERROR: gnustep-base/gnustep-base-1.24.3 failed (compile phase):
 [31;01m*[0m   emake failed
 [31;01m*[0m 
 [31;01m*[0m If you need support, post the output of `emerge --info '=gnustep-base/gnustep-base-1.24.3'`,
 [31;01m*[0m the complete build log and the output of `emerge -pqv '=gnustep-base/gnustep-base-1.24.3'`.
 [31;01m*[0m The complete build log is located at '/var/log/portage/gnustep-base:gnustep-base-1.24.3:20130414-065236.log'.
 [31;01m*[0m For convenience, a symlink to the build log is located at '/var/portage/gnustep-base/gnustep-base-1.24.3/temp/build.log'.
 [31;01m*[0m The ebuild environment file is located at '/var/portage/gnustep-base/gnustep-base-1.24.3/temp/environment'.
 [31;01m*[0m Working directory: '/var/portage/gnustep-base/gnustep-base-1.24.3/work/gnustep-base-1.24.3'
 [31;01m*[0m S: '/var/portage/gnustep-base/gnustep-base-1.24.3/work/gnustep-base-1.24.3 ...
Comment 6 Lukasz Wojciech Hebda 2013-08-11 17:03:39 UTC
compiling gnustep-base/gnustep-make with native-exceptions should solve exception handler error
Comment 7 adr 2013-08-12 10:45:13 UTC
(In reply to Lukasz Wojciech Hebda from comment #6)
Lukasz, thanks for your help. I tried enabling native-exceptions on gnustep-make last April, but I gave up to get Clang working, hoping for more luck in future. I tried again now, building the packages twice. After that I run gnustep-updater. Configure from gnustep-make exits with a segmentation fault in the "Check whether Objective-C /really/ works" section. Because this is different from the original error and the one in in comment #6, I'm closing this bug report. I'll report this upstream. I think the bug belongs there.
Comment 8 adr 2014-07-19 16:55:58 UTC
Reopened; tried again. It seems that =gnustep-base/gnustep-base-1.24.6-r1 configure expects /usr/lib/libobjc.so.4 to be there. When created with `ln -s libobjc.so.4.6 /usr/lib/libobjc.so.4', the problem is gone. I'm using =gnustep-base/libobjc2-1.7, that doesn't create this symlink.

After this, I can recompile most of the other installed gnustep packages, but run into other problems (a missing header file with USE="cups" and =gnustep-base:gnustep-gui-0.24.0; 3x a segmentation fault in the "plmerge" part when emerging =gnustep-base:gnustep-back-cairo, =gnustep-apps:systempreferences-1.2.0 and =gnustep-apps:gworkspace-0.9.2). Apps like GWorkspace, MPDCon and TextEdit segfault now. :-/
Comment 9 adr 2014-07-19 18:48:40 UTC
(In reply to adr from comment #8)
> Apps like GWorkspace, MPDCon and TextEdit segfault now. :-/
...when run (emerge went well).

Probably because of cairo could not be rebuild, and I borked things? (I used `emerge @gnustep', and did `emerge --resume --skip-first' 4x. :D
Comment 10 adr 2014-07-20 06:38:55 UTC
Created attachment 381080 [details]
emerge --info

I think the cups and plmerge errors better have a separate bug report, as they seem not related to building with clang (plmerge was rebuilt as part of gnustep-base, and works OK in emerge of other packages according to the build logs).

So, I guess the only thing left to close this bug report, is the missing symlink /usr/lib/libobjc.so.4
Comment 11 adr 2014-07-20 07:46:27 UTC
Created attachment 381086 [details]
emerge --info '=gnustep-base/gnustep-base-1.24.6-r1'
Comment 12 adr 2014-07-20 07:47:50 UTC
Created attachment 381088 [details]
emerge -pqv '=gnustep-base/gnustep-base-1.24.6-r1'
Comment 13 adr 2014-07-20 07:51:17 UTC
Created attachment 381090 [details]
Build log (without /usr/lib/libobjc.so.4 symlink)
Comment 14 adr 2014-07-20 07:52:16 UTC
Created attachment 381092 [details]
Config log (without /usr/lib/libobjc.so.4 symlink)
Comment 15 adr 2014-07-20 07:54:38 UTC
Created attachment 381094 [details]
/var/db/pkg/gnustep-base/libobjc2-1.7/CONTENTS
Comment 16 adr 2014-07-22 09:36:52 UTC
Created attachment 381326 [details]
emerge -pqv @gnustep
Comment 17 Bernard Cafarelli gentoo-dev 2015-05-20 11:26:58 UTC
(In reply to adr from comment #10)
> Created attachment 381080 [details]
> emerge --info
> 
> I think the cups and plmerge errors better have a separate bug report, as
> they seem not related to building with clang (plmerge was rebuilt as part of
> gnustep-base, and works OK in emerge of other packages according to the
> build logs).
> 
> So, I guess the only thing left to close this bug report, is the missing
> symlink /usr/lib/libobjc.so.4

Sorry for the delay, I just found I never committed the fix for this one :/

1.7-r1 fixes soname so we have the same as in previous 1.6.x releases