Re: GNUstep base fails - libobjc2 on NetBSD x86
Hi David, thanks, please follow below for the dump. Riccardo David Chisnall wrote: This is very odd. I don’t suppose that, when you modify the CFLAGS you’re removing the -fPIC? Aside from that, I "hope" not - the CFLAGS were empty, I just added my entries. To be sure, I added extra -fPIC and recompiled, but I still get that error. can you use objdump to print the relocations? This is not a very helpful error message and without knowing where the text relocation is, I can’t suggest how to fix it. I believe the only text relocations that we had in the assembly routines were fixed some years back. The output below, I did use -R for dynamic relocations, since -r did not printout anything. isengard$ objdump -r libobjc.so.4.6 libobjc.so.4.6: file format elf32-i386 isengard$ objdump -R libobjc.so.4.6 libobjc.so.4.6: file format elf32-i386 DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 00055c44 R_386_RELATIVE *ABS* 00055c60 R_386_RELATIVE *ABS* 00055c68 R_386_RELATIVE *ABS* 00055c70 R_386_RELATIVE *ABS* 00055c74 R_386_RELATIVE *ABS* 00055d64 R_386_RELATIVE *ABS* 00055d6c R_386_RELATIVE *ABS* 00055d80 R_386_RELATIVE *ABS* 00055d88 R_386_RELATIVE *ABS* 00055d90 R_386_RELATIVE *ABS* 00055d9c R_386_RELATIVE *ABS* 00055da4 R_386_RELATIVE *ABS* 00055dac R_386_RELATIVE *ABS* 00055db8 R_386_RELATIVE *ABS* 00055dc0 R_386_RELATIVE *ABS* 00055dc8 R_386_RELATIVE *ABS* 00055dd4 R_386_RELATIVE *ABS* 00055ddc R_386_RELATIVE *ABS* 00055de4 R_386_RELATIVE *ABS* 00055df0 R_386_RELATIVE *ABS* 00055df8 R_386_RELATIVE *ABS* 00055e00 R_386_RELATIVE *ABS* 00055e0c R_386_RELATIVE *ABS* 00055e14 R_386_RELATIVE *ABS* 00055e1c R_386_RELATIVE *ABS* 00055e40 R_386_RELATIVE *ABS* 00055e44 R_386_RELATIVE *ABS* 00055e50 R_386_RELATIVE *ABS* 00055e54 R_386_RELATIVE *ABS* 00055e60 R_386_RELATIVE *ABS* 00055e64 R_386_RELATIVE *ABS* 00055e70 R_386_RELATIVE *ABS* 00055e74 R_386_RELATIVE *ABS* 00055e80 R_386_RELATIVE *ABS* 00055e84 R_386_RELATIVE *ABS* 00055e90 R_386_RELATIVE *ABS* 00055e94 R_386_RELATIVE *ABS* 00055ea0 R_386_RELATIVE *ABS* 00055ea4 R_386_RELATIVE *ABS* 00055eb0 R_386_RELATIVE *ABS* 00055eb4 R_386_RELATIVE *ABS* 00055ec0 R_386_RELATIVE *ABS* 00055ec4 R_386_RELATIVE *ABS* 00055ed0 R_386_RELATIVE *ABS* 00055ed4 R_386_RELATIVE *ABS* 00055ee0 R_386_RELATIVE *ABS* 00055ee4 R_386_RELATIVE *ABS* 00055ef0 R_386_RELATIVE *ABS* 00055ef4 R_386_RELATIVE *ABS* 00055f00 R_386_RELATIVE *ABS* 00055f04 R_386_RELATIVE *ABS* 00055f10 R_386_RELATIVE *ABS* 00055f14 R_386_RELATIVE *ABS* 00055f20 R_386_RELATIVE *ABS* 00055f24 R_386_RELATIVE *ABS* 00055f30 R_386_RELATIVE *ABS* 00055f34 R_386_RELATIVE *ABS* 00055f40 R_386_RELATIVE *ABS* 00055f44 R_386_RELATIVE *ABS* 00055f50 R_386_RELATIVE *ABS* 00055f54 R_386_RELATIVE *ABS* 00055f60 R_386_RELATIVE *ABS* 00055f64 R_386_RELATIVE *ABS* 00055f70 R_386_RELATIVE *ABS* 00055f74 R_386_RELATIVE *ABS* 00055f80 R_386_RELATIVE *ABS* 00055f84 R_386_RELATIVE *ABS* 00055f90 R_386_RELATIVE *ABS* 00055f94 R_386_RELATIVE *ABS* 00055fa0 R_386_RELATIVE *ABS* 00055fa4 R_386_RELATIVE *ABS* 00055fb0 R_386_RELATIVE *ABS* 00055fb4 R_386_RELATIVE *ABS* 00055fc0 R_386_RELATIVE *ABS* 00055fc4 R_386_RELATIVE *ABS* 00055fd0 R_386_RELATIVE *ABS* 00055fd4 R_386_RELATIVE *ABS* 00055fe0 R_386_RELATIVE *ABS* 00055fe4 R_386_RELATIVE *ABS* 00055ff0 R_386_RELATIVE *ABS* 00055ff4 R_386_RELATIVE *ABS* 00056000 R_386_RELATIVE *ABS* 00056004 R_386_RELATIVE *ABS* 00056010 R_386_RELATIVE *ABS* 00056014 R_386_RELATIVE *ABS* 00056020 R_386_RELATIVE *ABS* 00056024 R_386_RELATIVE *ABS* 00056030 R_386_RELATIVE *ABS* 00056034 R_386_RELATIVE *ABS* 00056040 R_386_RELATIVE *ABS* 00056044 R_386_RELATIVE *ABS* 00056050 R_386_RELATIVE *ABS* 00056054 R_386_RELATIVE *ABS* 00056060 R_386_RELATIVE *ABS* 00056064 R_386_RELATIVE *ABS* 00056070 R_386_RELATIVE *ABS* 00056074 R_386_RELATIVE *ABS* 00056080 R_386_RELATIVE *ABS* 00056084 R_386_RELATIVE *ABS* 00056090 R_386_RELATIVE *ABS* 00056094 R_386_RELATIVE *ABS* 000560a0 R_386_RELATIVE *ABS* 000560a4 R_386_RELATIVE *ABS* 000560b0 R_386_RELATIVE *ABS* 000560b4 R_386_RELATIVE *ABS* 000560c0 R_386_RELATIVE *ABS* 000560c4 R_386_RELATIVE *ABS* 000560d0 R_386_RELATIVE *ABS* 000560d4 R_386_RELATIVE *ABS* 000560e0 R_386_RELATIVE *ABS* 000560e4 R_386_RELATIVE *ABS* 000560f0 R_386_RELATIVE *ABS* 000560f4 R_386_RELATIVE *ABS* 00056100 R_386_RELATIVE *ABS* 00056104 R_386_RELATIVE *ABS* 00056110 R_386_RELATIVE *ABS* 00056114 R_386_RELATIVE *ABS* 00056120 R_386_RELATIVE *ABS* 00056124 R_386_RELATIVE *ABS* 00056130 R_386_RELATIVE *ABS* 00056134 R_386_RELATIVE *ABS* 00056140 R_386_RELATIVE *ABS* 00056144 R_386_RELATIVE
Re: GNUstep base fails - libobjc2 on NetBSD x86
Hi Ricardo, > On 3 Jan 2021, at 22:22, Riccardo Mottola wrote: > > /home/multix/code/libobjc2/Build/libobjc.so.4.6: text relocations > /home/multix/code/libobjc2/Build/libobjc.so.4.6: Cannot write-enable text > segment: Permission denied This is very odd. I don’t suppose that, when you modify the CFLAGS you’re removing the -fPIC? Aside from that, can you use objdump to print the relocations? This is not a very helpful error message and without knowing where the text relocation is, I can’t suggest how to fix it. I believe the only text relocations that we had in the assembly routines were fixed some years back. David
Re: GNUstep base fails - libobjc2 on NetBSD x86
Hi, Frederik Seiffert wrote: Sorry I’m not familiar with NetBSD or PaX, but I’ve seen messages on the mailing list e.g. from Wolfgang Lux that suggest they got libobjc2 working on NetBSD. Wolfgang is always a steap ahead of me :) Maybe you could share how you’re building libobjc2? Sure, but I tried to change it the leat possible: First, I configured make with: ./configure --with-library-combo=ng-gnu-gnu prefix=/ --with-layout=gnustep Then, in libobjc2, with "ccmake ." I changed some parameters: CMAKE_CXX_FLAGS -march=i686 -mtune=i686 CMAKE_C_FLAGS -march=i686 -mtune=i686 (these are necessary so that gcc does nto need external libatomic, causing other issues) And I tried fiddling with the linker: CMAKE_LINKER /usr/pkg/gnu/bin/ld.gold but using bfd did not improve things either ineed, running "make test" has all tests fail, and I see: /home/multix/code/libobjc2/Build/libobjc.so.4.6: text relocations /home/multix/code/libobjc2/Build/libobjc.so.4.6: Cannot write-enable text segment: Permission denied So this has nothing with base, but libobjc2 is broken by itself. Riccardo
Re: GNUstep base fails - libobjc2 on NetBSD x86
Hi Riccardo, Sorry I’m not familiar with NetBSD or PaX, but I’ve seen messages on the mailing list e.g. from Wolfgang Lux that suggest they got libobjc2 working on NetBSD. Maybe you could share how you’re building libobjc2? Frederik > Am 03.01.2021 um 23:22 schrieb Riccardo Mottola : > > Hi Frederik, > > > On 1/3/21 3:26 PM, Frederik Seiffert wrote: >> Looks like the conftest executable is aborting. Can you try running it with >> a debugger to see where it fails? > > > I couldn't find the conftest binary after the failure, seems it does get > removed immediately. I don't remember if there is a command to save the > generated executables. > > I did reconstruct it from the config.log, wrote the soruce code in a file > then run the exact same command that is written there. > > It fails this way: > > (gdb) r > Starting program: /home/multix/code/libs-base/conftest > /System/Library/Libraries/libobjc.so.4.6: text relocations > [Inferior 1 (process 6265) exited normally] > (gdb) bt > No stack. > > It appears to me it does not even run and doesn't like something in my > libobjc.so. > > I fear, it really is not built correctly then - I got it building but it is > not working on NetBSD/i386 > > Well, I should have checked: > > 0% tests passed, 186 tests failed out of 186 > > I found this in the logs: > > /home/multix/code/libobjc2/Build/libobjc.so.4.6: text relocations > /home/multix/code/libobjc2/Build/libobjc.so.4.6: Cannot write-enable text > segment: Permission denied > > I wonder if we are violiting some permissions of PaX ? I cannot set PaX on > libraries though, only on executables. > > Or some address is bogus or other havoc is going on. > > > Riccardo >
Re: GNUstep base fails - libobjc2 on NetBSD x86
Hi Frederik, On 1/3/21 3:26 PM, Frederik Seiffert wrote: Looks like the conftest executable is aborting. Can you try running it with a debugger to see where it fails? I couldn't find the conftest binary after the failure, seems it does get removed immediately. I don't remember if there is a command to save the generated executables. I did reconstruct it from the config.log, wrote the soruce code in a file then run the exact same command that is written there. It fails this way: (gdb) r Starting program: /home/multix/code/libs-base/conftest /System/Library/Libraries/libobjc.so.4.6: text relocations [Inferior 1 (process 6265) exited normally] (gdb) bt No stack. It appears to me it does not even run and doesn't like something in my libobjc.so. I fear, it really is not built correctly then - I got it building but it is not working on NetBSD/i386 Well, I should have checked: 0% tests passed, 186 tests failed out of 186 I found this in the logs: /home/multix/code/libobjc2/Build/libobjc.so.4.6: text relocations /home/multix/code/libobjc2/Build/libobjc.so.4.6: Cannot write-enable text segment: Permission denied I wonder if we are violiting some permissions of PaX ? I cannot set PaX on libraries though, only on executables. Or some address is bogus or other havoc is going on. Riccardo
Re: GNUstep base fails - libobjc2 on NetBSD x86
Hi Riccardo,
Looks like the conftest executable is aborting. Can you try running it with a
debugger to see where it fails?
Frederik
> Am 02.01.2021 um 23:14 schrieb Riccardo Mottola :
>
> Hi,
>
> I am still struggling to get GNUstep running on NetBSD/i386... strange thing.
> I am trying to get it runing with libobjc2. I just updated that one too.
> WIth David some fixes where done in libobjc2 some weeks ago.
>
> make:
> $ ./configure --with-library-combo=ng-gnu-gnu prefix=/ --with-layout=gnustep
>
>
> I configured libobcj2 with:
> CMAKE_C_FLAGS-march=i686 -mtune=i686
>
>
> the arch is to avoid atomics issues on NetBSD.
>
> I tried both the bfd and the cold linker no help
>
> Currently I fail with:
> configure:7872: checking whether objc really works
> configure:7892: clang -o conftest -g -O2 -I/Local/Library/Headers
> -I/Local/Library/Headers -I/System/Library/Headers -
> I/usr/pkg/include -I/System/Library/Headers -x objective-c
> -L/Local/Library/Libraries -L/Local/Library/Libraries -L/S
> ystem/Library/Libraries -Wl,-R/usr/pkg/lib -L/usr/pkg/lib
> -L/System/Library/Libraries conftest.c -lrt -lpthread -pthre
> ad -fexceptions -rdynamic -fobjc-runtime=gnustep-2.0 -fblocks
> -L/home/multix/GNUstep/Library/Libraries -L/Local/Library
> /Libraries -L/System/Library/Libraries -Wl,-R/usr/pkg/lib -L/usr/pkg/lib
> -lobjc -lm >&5
> In file included from conftest.c:104:
> 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() [-W
> deprecated-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:7892: $? = 0
> configure:7892: ./conftest
> [1] Abort trap ./conftest${ac_exeext}
> configure:7892: $? = 134
>
>
> any ideas?
>
> Riccardo
>
>
