problems compiling on solaris 10

[Riccardo Mottola]

Hi,

I installed gcc 4.8.0 from OpenCSW on solaris 10 (including objc and
objc runtime of course). When configuring make, I notice that the test
for threads fails.

checking for custom shared objc library... NONE
checking for the flag to link libobjc... -lobjc
checking whether objc has thread support... no


I thus inspected the test and tried to compile config_thread.m manually.

gcc -o conftest -g -O2 -x objective-c -I. -fgnu-runtime -DGNU_RUNTIME
config_thread.m -lobjc -lpthread
The result is a seg-fault, exactly as in the config.log

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
__objc_responds_to (sel=0x0, object=0xff35c098 <_OBJC_Class_Object>)
at
/home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.8.0/libobjc/sendmsg.c:397
397
/home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.8.0/libobjc/sendmsg.c:
No such file or directory.
(gdb) bt
#0 __objc_responds_to (sel=0x0, object=0xff35c098 <_OBJC_Class_Object>)
at
/home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.8.0/libobjc/sendmsg.c:397
#1 __objc_forward (object=0xff35c098 <_OBJC_Class_Object>,
sel=0x20ef4 <_OBJC_SELECTOR_TABLE>, args=0xffbffd08)
at
/home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.8.0/libobjc/sendmsg.c:904
#2 0xff346344 in __objc_word_forward (rcv=<optimized out>,
op=0x20ef4 <_OBJC_SELECTOR_TABLE>)
at
/home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.8.0/libobjc/sendmsg.c:843
#3 0x00010c34 in main () at config_thread.m:26
(gdb) q


it is very strange that it looks for a file not there (but it is of the
gcc build system apparently). I'm confused. Perhaps it is the debugger
acting up?

What I found out is that if compilation is done without the two runtime
flags, that is:
gcc -o conftest -g -O2 -x objective-c -I. config_thread.m -lobjc
-lpthread

I get no crash. Even
gcc -o conftest -g -O2 -x objective-c -I. -fgnu-runtime
config_thread.m -lobjc -lpthread
is enough.

That means, the problem is -DGNU_RUNTIME. In fact, compiling with this
define, I get a lot of warnings, which I don't get otherwise.
config_thread.m:7:1: warning: incomplete implementation of class
'NXConstantString' [enabled by default]
@end
^
config_thread.m:7:1: warning: method definition for '-length' not found
[enabled by default]
config_thread.m:7:1: warning: method definition for '-cString' not found
[enabled by default]
config_thread.m: In function 'main':
config_thread.m:26:3: warning: 'Object' may not respond to '+new'
[enabled by default]
id o = [Object new];
^
config_thread.m:26:3: warning: (Messages without a matching method
signature [enabled by default]
config_thread.m:26:3: warning: will be assumed to return 'id' and accept
[enabled by default]
config_thread.m:26:3: warning: '...' as arguments.) [enabled by default]

I tried substituding new with alloc+init, but I get the waring that
alloc is not specified.

Gcc's Object.h indeed is extremely minimal and doesn't specify either
new nor alloc.

Riccardo

[Riccardo Mottola]

Hi!

does really nobody have a hint on how to continue on this? The test is
minimal and the stacktrace is pretty low-level.

Riccardo

[Riccardo Mottola]

Hi,

Sebastian Reitenbach wrote:

>
> On Monday, April 15, 2013 19:43 CEST, Riccardo Mottola <riccardo...@libero.it> wrote:
>
>> Hi!
>>
>> does really nobody have a hint on how to continue on this? The test is
>> minimal and the stacktrace is pretty low-level.

> does gcc segfault, while you are compiling, or does the program segfault,
> when you run it?
> From the backtrace I would guess the latter, but I may be wrong.
You are right, it is the test program. config_thread.m As I wrote, I am
able to reproduce the problem outside the configure environment and
played also with the passed compilation options. The -DGNU_RUNTIME
causes all the warnings and problems, but why precisely I don't know.
I noticed the warnings happen also on other platforms, but not the
seg-fault.
> In any case, I think, the libobjc you are using has debugging symbols in it,
> therefore it knows the location where it was compiled on, under home/maciej/...
> When you put the sources there, then the list command in gdb should show you
> something more useful.
>
I guess that is where the building of the binary package happened. I
could try playing with some links and get hold of the source + potential
patches.

R