Summary: | 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) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | adr <adr> |
Component: | [OLD] Development | Assignee: | Gentoo Gnustep project <gnustep> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info '=gnustep-base/gnustep-base-1.24.3
build log emerge -pqv '=gnustep-base/gnustep-base-1.24.3' work/gnustep-base-1.24.3/config.log emerge --info emerge --info '=gnustep-base/gnustep-base-1.24.6-r1' emerge -pqv '=gnustep-base/gnustep-base-1.24.6-r1' Build log (without /usr/lib/libobjc.so.4 symlink) Config log (without /usr/lib/libobjc.so.4 symlink) /var/db/pkg/gnustep-base/libobjc2-1.7/CONTENTS emerge -pqv @gnustep |
Description
adr
2013-04-12 10:43:25 UTC
Created attachment 345360 [details]
emerge --info '=gnustep-base/gnustep-base-1.24.3
Created attachment 345362 [details]
build log
Created attachment 345364 [details]
emerge -pqv '=gnustep-base/gnustep-base-1.24.3'
Created attachment 345366 [details]
work/gnustep-base-1.24.3/config.log
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 ... compiling gnustep-base/gnustep-make with native-exceptions should solve exception handler error (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. 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. :-/ (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 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
Created attachment 381086 [details]
emerge --info '=gnustep-base/gnustep-base-1.24.6-r1'
Created attachment 381088 [details]
emerge -pqv '=gnustep-base/gnustep-base-1.24.6-r1'
Created attachment 381090 [details]
Build log (without /usr/lib/libobjc.so.4 symlink)
Created attachment 381092 [details]
Config log (without /usr/lib/libobjc.so.4 symlink)
Created attachment 381094 [details]
/var/db/pkg/gnustep-base/libobjc2-1.7/CONTENTS
Created attachment 381326 [details]
emerge -pqv @gnustep
(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 |