subject:"make fails in gnustep base"

Re: make fails in gnustep base

2018-09-04 Thread Andreas Fink

The bad thing is that pkg-config puts the order of linking exactly in the order 
which test2 is in
which means the root object is last in the chain.


> On 4 Sep 2018, at 08:56, Andreas Fink  wrote:
> 
> 
> Here is a simple test case illustrating the problem
> 
> TestObject4  inherits from TestObjec3 inherits from TestObject2 inherits from 
> TestObject1
> 
> All testobjects are compiled into a shared library
> 
> do a make ; make install
> and then run test1, test2, test3, test4 binaries.
> They all run the same code. The only difference is the order of the linkage 
> of the shared libraries
> 
> 
> 
> 
> test1 runs correctly.
> test2 produces rubbish data.
> 
> 
> root@gnustep:~/gitlab/testcase/test2# ./test1
> 2018-09-04 08:54:42.162 test1[27822:27822] t1= _int1=1
> _int2=2
> _string3=s3
> _int4=4
> _string5=s5
> 2018-09-04 08:54:42.162 test1[27822:27822] t2= _int1=1
> _int2=2
> _string3=s3
> _int4=4
> _string5=s5
> _int6=6
> _int7=7
> _string8=s8
> _int9=9
> _string10=s10
> 2018-09-04 08:54:42.162 test1[27822:27822] t3= _int1=331
> _int2=332
> _string3=s333
> _int4=334
> _string5=s335
> _int6=6
> _int7=7
> _string8=s8
> _int9=9
> _string10=s10
> 2018-09-04 08:54:42.162 test1[27822:27822] t4= _int1=331
> _int2=332
> _string3=s333
> _int4=334
> _string5=s335
> _int6=66
> _int7=77
> _string8=s88
> _int9=99
> _string10=s1010
> root@gnustep:~/gitlab/testcase/test2# ./test2
> 2018-09-04 08:54:51.406 test2[27823:27823] t1= _int1=420758136
> _int2=420758136
> _string3=s5
> _int4=420758136
> _string5=s5
> 2018-09-04 08:54:51.407 test2[27823:27823] t2= _int1=420758136
> _int2=420758136
> _string3=s5
> _int4=420758136
> _string5=s5
> _int6=9
> _int7=9
> _string8=17545478275073
> _int9=9
> _string10=s10
> 2018-09-04 08:54:51.407 test2[27823:27823] t3= _int1=425022016
> _int2=425022016
> _string3=s335
> _int4=425022016
> _string5=s335
> _int6=9
> _int7=9
> _string8=17545478275073
> _int9=9
> _string10=s10
> 2018-09-04 08:54:51.407 test2[27823:27823] t4= _int1=425022016
> _int2=425022016
> _string3=s335
> _int4=425022016
> _string5=s335
> _int6=99
> _int7=99
> _string8=6.93489458547e-310
> _int9=99
> _string10=s1010
> 
> 
> 
>> On 4 Sep 2018, at 07:37, Andreas Fink  wrote:
>> 
>> 
>> 
>>> On 3 Sep 2018, at 23:40, Ivan Vučica  wrote:
>>> 
>>> So, uh, libulibtcap depends on code in libasn1? Library order matters
>>> to the linker.
>> 
>> Sure thats why we have linkers. it dynamically links things together.  These 
>> are all dynamic libraries so the final linking should find all references or 
>> bail out.
>> However I do not get a link failure. At the end everything is linked 
>> together. I have runtime errors and very bizarre ones. Not crashes but 
>> _some_ properties not being set properly.
>> 
>>> If you can't fix it (and it sounds like you can?) then you can pass
>>> --start-group and --end-group to the linker so it performs multiple
>>> passes.
>>> 
>>> If you are passing the options --start-group and --end-group to the
>>> compiler instead of the linker, you may need to use -Wl,--start-group
>>> and -Wl,--end-group.
>>> 
>>> What I'm saying depends on the linker, of course, and it's been a
>>> while since I needed this, making it hard for me to know which
>>> particular linker I'm talking about here. :-)
>> 
>> I would like to understand whats really happening here. I can understand 
>> things like it doesn't find symbols. These things would at least make sense. 
>> But this behaviour is very irrational to me.
>> 
>> 
>> 
>> 
>> ___
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-09-04 Thread Andreas Fink


Here is a simple test case illustrating the problem

TestObject4  inherits from TestObjec3 inherits from TestObject2 inherits from 
TestObject1

All testobjects are compiled into a shared library

do a make ; make install
and then run test1, test2, test3, test4 binaries.
They all run the same code. The only difference is the order of the linkage of 
the shared libraries



test2.tar.gz
Description: GNU Zip compressed data



test1 runs correctly.
test2 produces rubbish data.


root@gnustep:~/gitlab/testcase/test2# ./test1
2018-09-04 08:54:42.162 test1[27822:27822] t1= _int1=1
 _int2=2
 _string3=s3
 _int4=4
 _string5=s5
2018-09-04 08:54:42.162 test1[27822:27822] t2= _int1=1
 _int2=2
 _string3=s3
 _int4=4
 _string5=s5
 _int6=6
 _int7=7
 _string8=s8
 _int9=9
 _string10=s10
2018-09-04 08:54:42.162 test1[27822:27822] t3= _int1=331
 _int2=332
 _string3=s333
 _int4=334
 _string5=s335
 _int6=6
 _int7=7
 _string8=s8
 _int9=9
 _string10=s10
2018-09-04 08:54:42.162 test1[27822:27822] t4= _int1=331
 _int2=332
 _string3=s333
 _int4=334
 _string5=s335
 _int6=66
 _int7=77
 _string8=s88
 _int9=99
 _string10=s1010
root@gnustep:~/gitlab/testcase/test2# ./test2
2018-09-04 08:54:51.406 test2[27823:27823] t1= _int1=420758136
 _int2=420758136
 _string3=s5
 _int4=420758136
 _string5=s5
2018-09-04 08:54:51.407 test2[27823:27823] t2= _int1=420758136
 _int2=420758136
 _string3=s5
 _int4=420758136
 _string5=s5
 _int6=9
 _int7=9
 _string8=17545478275073
 _int9=9
 _string10=s10
2018-09-04 08:54:51.407 test2[27823:27823] t3= _int1=425022016
 _int2=425022016
 _string3=s335
 _int4=425022016
 _string5=s335
 _int6=9
 _int7=9
 _string8=17545478275073
 _int9=9
 _string10=s10
2018-09-04 08:54:51.407 test2[27823:27823] t4= _int1=425022016
 _int2=425022016
 _string3=s335
 _int4=425022016
 _string5=s335
 _int6=99
 _int7=99
 _string8=6.93489458547e-310
 _int9=99
 _string10=s1010



> On 4 Sep 2018, at 07:37, Andreas Fink  wrote:
> 
> 
> 
>> On 3 Sep 2018, at 23:40, Ivan Vučica  wrote:
>> 
>> So, uh, libulibtcap depends on code in libasn1? Library order matters
>> to the linker.
> 
> Sure thats why we have linkers. it dynamically links things together.  These 
> are all dynamic libraries so the final linking should find all references or 
> bail out.
> However I do not get a link failure. At the end everything is linked 
> together. I have runtime errors and very bizarre ones. Not crashes but _some_ 
> properties not being set properly.
> 
>> If you can't fix it (and it sounds like you can?) then you can pass
>> --start-group and --end-group to the linker so it performs multiple
>> passes.
>> 
>> If you are passing the options --start-group and --end-group to the
>> compiler instead of the linker, you may need to use -Wl,--start-group
>> and -Wl,--end-group.
>> 
>> What I'm saying depends on the linker, of course, and it's been a
>> while since I needed this, making it hard for me to know which
>> particular linker I'm talking about here. :-)
> 
> I would like to understand whats really happening here. I can understand 
> things like it doesn't find symbols. These things would at least make sense. 
> But this behaviour is very irrational to me.
> 
> 
> 
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-09-03 Thread Andreas Fink

> On 3 Sep 2018, at 23:40, Ivan Vučica  wrote:
> 
> So, uh, libulibtcap depends on code in libasn1? Library order matters
> to the linker.

Sure thats why we have linkers. it dynamically links things together.  These 
are all dynamic libraries so the final linking should find all references or 
bail out.
However I do not get a link failure. At the end everything is linked together. 
I have runtime errors and very bizarre ones. Not crashes but _some_ properties 
not being set properly.

> If you can't fix it (and it sounds like you can?) then you can pass
> --start-group and --end-group to the linker so it performs multiple
> passes.
> 
> If you are passing the options --start-group and --end-group to the
> compiler instead of the linker, you may need to use -Wl,--start-group
> and -Wl,--end-group.
> 
> What I'm saying depends on the linker, of course, and it's been a
> while since I needed this, making it hard for me to know which
> particular linker I'm talking about here. :-)

I would like to understand whats really happening here. I can understand things 
like it doesn't find symbols. These things would at least make sense. But this 
behaviour is very irrational to me.

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-09-03 Thread Ivan Vučica

So, uh, libulibtcap depends on code in libasn1? Library order matters
to the linker.

If you can't fix it (and it sounds like you can?) then you can pass
--start-group and --end-group to the linker so it performs multiple
passes.

If you are passing the options --start-group and --end-group to the
compiler instead of the linker, you may need to use -Wl,--start-group
and -Wl,--end-group.

What I'm saying depends on the linker, of course, and it's been a
while since I needed this, making it hard for me to know which
particular linker I'm talking about here. :-)
On Mon, Sep 3, 2018 at 9:18 AM Andreas Fink  wrote:
>
> I recompiled all with clang7 on a freshly installed Debian9. Now all the 
> tests in libobjc2 pass and gnustep-base all except a few pass (the others are 
> probably broken since a long time but are minor things).
> My application however still doesn't run properly. I have code taking apart 
> some ASN1 which out of a sudden produces lots of NULL pointers instead which 
> is totally puzzling as this is test cases which worked since ages.
>
> I've broken it down to a test case to isolate the cause and came to the 
> conclusion that if two libraries are linked in a very specific order, I have 
> this problem. If they are linked in the reverse order, I do not have it.
> They are all dynamic libraries and there's no special cases here.  library 
> ulib is my base library where my root class resides. ulibasn1 is my ASN1 
> decoding library which subclasses from ulib. ulibtcap is another class which 
> indirectly inherits from ulib but uses ulibasn1 as well.
>
> if I link   -lulibasn1  -lulibtcap  it works
> if I link   -lulibtcap -lulibasn1 it fails.
>
> I dont understand how this can happen. There are no unique names which should 
> overlap or the like.
>
> Does anyone have a clue what could cause this?
> The link order in my case is generated by pkg-config automatically.
>
> My test case uses ulibasn1 and ulib and nothing else. If I add ulibtcap to 
> the linking (but not being used at all inside my test case) the problem 
> starts appearing. Really weird!
>
>
>
> > On 31 Aug 2018, at 10:29, David Chisnall  wrote:
> >
> > On 31/08/2018 09:22, Andreas Fink wrote:
> >> all latest compiled from these sources:
> >
> > It looks like someone at Apple broke blocks on all ELF platforms a couple 
> > of weeks ago.  It's not been merged to the 7 release branch though, so 
> > building from that should fix things for you.
> >
> > David
> >
>
>
>
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-09-03 Thread Andreas Fink

I recompiled all with clang7 on a freshly installed Debian9. Now all the tests 
in libobjc2 pass and gnustep-base all except a few pass (the others are 
probably broken since a long time but are minor things).
My application however still doesn't run properly. I have code taking apart 
some ASN1 which out of a sudden produces lots of NULL pointers instead which is 
totally puzzling as this is test cases which worked since ages.

I've broken it down to a test case to isolate the cause and came to the 
conclusion that if two libraries are linked in a very specific order, I have 
this problem. If they are linked in the reverse order, I do not have it.
They are all dynamic libraries and there's no special cases here.  library ulib 
is my base library where my root class resides. ulibasn1 is my ASN1 decoding 
library which subclasses from ulib. ulibtcap is another class which indirectly 
inherits from ulib but uses ulibasn1 as well.

if I link   -lulibasn1  -lulibtcap  it works
if I link   -lulibtcap -lulibasn1 it fails.

I dont understand how this can happen. There are no unique names which should 
overlap or the like.

Does anyone have a clue what could cause this?
The link order in my case is generated by pkg-config automatically.

My test case uses ulibasn1 and ulib and nothing else. If I add ulibtcap to the 
linking (but not being used at all inside my test case) the problem starts 
appearing. Really weird!

> On 31 Aug 2018, at 10:29, David Chisnall  wrote:
> 
> On 31/08/2018 09:22, Andreas Fink wrote:
>> all latest compiled from these sources:
> 
> It looks like someone at Apple broke blocks on all ELF platforms a couple of 
> weeks ago.  It's not been merged to the 7 release branch though, so building 
> from that should fix things for you.
> 
> David
> 

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-08-31 Thread David Chisnall


On 31/08/2018 10:23, Andreas Fink wrote:

using clang7 is no good neither. Tons of tests fail.


I can't reproduce this.  Building both the trunk and 1.9 branches with 
the current llvm release_70 branch, all tests pass.


David

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-08-31 Thread Andreas Fink

using clang7 is no good neither. Tons of tests fail.


The following tests FAILED:
  1 - alias (SEGFAULT)
  2 - alias_optimised (SEGFAULT)
  5 - alignTest (SEGFAULT)
  6 - alignTest_optimised (SEGFAULT)
  9 - AllocatePair (SEGFAULT)
 10 - AllocatePair_optimised (SEGFAULT)
 13 - ARCTest_arc (SEGFAULT)
 14 - ARCTest_arc_optimised (SEGFAULT)
 17 - AssociatedObject (SEGFAULT)
 18 - AssociatedObject_optimised (SEGFAULT)
 21 - AssociatedObject2 (SEGFAULT)
 22 - AssociatedObject2_optimised (SEGFAULT)
 25 - BlockImpTest (SEGFAULT)
 26 - BlockImpTest_optimised (SEGFAULT)
 29 - BlockTest_arc (SEGFAULT)
 30 - BlockTest_arc_optimised (SEGFAULT)
 33 - ConstantString (SEGFAULT)
 34 - ConstantString_optimised (SEGFAULT)
 37 - Category (SEGFAULT)
 38 - Category_optimised (SEGFAULT)
 41 - ExceptionTest (SEGFAULT)
 42 - ExceptionTest_optimised (SEGFAULT)
 45 - Forward (SEGFAULT)
 46 - Forward_optimised (SEGFAULT)
 49 - ManyManySelectors (SEGFAULT)
 50 - ManyManySelectors_optimised (SEGFAULT)
 53 - NestedExceptions (SEGFAULT)
 54 - NestedExceptions_optimised (SEGFAULT)
 57 - PropertyAttributeTest (SEGFAULT)
 58 - PropertyAttributeTest_optimised (SEGFAULT)
 63 - ProtocolExtendedProperties_legacy (OTHER_FAULT)
 64 - ProtocolExtendedProperties_legacy_optimised (OTHER_FAULT)
 65 - PropertyIntrospectionTest (SEGFAULT)
 66 - PropertyIntrospectionTest_optimised (SEGFAULT)
 69 - PropertyIntrospectionTest2_arc (SEGFAULT)
 70 - PropertyIntrospectionTest2_arc_optimised (SEGFAULT)
 71 - PropertyIntrospectionTest2_arc_legacy (OTHER_FAULT)
 72 - PropertyIntrospectionTest2_arc_legacy_optimised (OTHER_FAULT)
 73 - ProtocolCreation (SEGFAULT)
 74 - ProtocolCreation_optimised (SEGFAULT)
 75 - ProtocolCreation_legacy (SEGFAULT)
 76 - ProtocolCreation_legacy_optimised (SEGFAULT)
 77 - ResurrectInDealloc_arc (SEGFAULT)
 78 - ResurrectInDealloc_arc_optimised (SEGFAULT)
 81 - RuntimeTest (SEGFAULT)
 82 - RuntimeTest_optimised (SEGFAULT)
 83 - RuntimeTest_legacy (Failed)
 84 - RuntimeTest_legacy_optimised (Failed)
 85 - WeakBlock_arc (SEGFAULT)
 86 - WeakBlock_arc_optimised (SEGFAULT)
 89 - WeakReferences_arc (SEGFAULT)
 90 - WeakReferences_arc_optimised (SEGFAULT)
 97 - ivar_arc (SEGFAULT)
 98 - ivar_arc_optimised (SEGFAULT)
101 - IVarOverlap (SEGFAULT)
102 - IVarOverlap_optimised (SEGFAULT)
105 - objc_msgSend (SEGFAULT)
106 - objc_msgSend_optimised (SEGFAULT)
113 - NilException (SEGFAULT)
114 - NilException_optimised (SEGFAULT)
117 - MethodArguments (SEGFAULT)
118 - MethodArguments_optimised (SEGFAULT)
121 - zeroSizedIVar (SEGFAULT)
122 - zeroSizedIVar_optimised (SEGFAULT)
125 - exchange (SEGFAULT)
126 - exchange_optimised (SEGFAULT)
137 - setSuperclass (SEGFAULT)
138 - setSuperclass_optimised (SEGFAULT)
141 - BoxedForeignException (SEGFAULT)
142 - BoxedForeignException_optimised (SEGFAULT)
145 - ForeignException (SEGFAULT)
146 - ForeignException_optimised (SEGFAULT)
149 - category_properties (SEGFAULT)
150 - category_properties_optimised (SEGFAULT)
151 - CXXExceptions (SEGFAULT)
152 - CXXExceptions_optimised (SEGFAULT)
155 - ObjCXXEHInterop (SEGFAULT)
156 - ObjCXXEHInterop_optimised (SEGFAULT)


> On 31 Aug 2018, at 10:38, Andreas Fink  wrote:
> 
> *facepalm*
> 
> its a constant race between bugfixes and introduction of other bugs  on the 
> other side... :)
> Thanks for the hint, I'll try release 7...
> 
> 
> 
>> On 31 Aug 2018, at 10:29, David Chisnall  wrote:
>> 
>> On 31/08/2018 09:22, Andreas Fink wrote:
>>> all latest compiled from these sources:
>> 
>> It looks like someone at Apple broke blocks on all ELF platforms a couple of 
>> weeks ago.  It's not been merged to the 7 release branch though, so building 
>> from that should fix things for you.
>> 
>> David
>> 
> 
> 
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-08-31 Thread Andreas Fink

*facepalm*

its a constant race between bugfixes and introduction of other bugs  on the 
other side... :)
Thanks for the hint, I'll try release 7...



> On 31 Aug 2018, at 10:29, David Chisnall  wrote:
> 
> On 31/08/2018 09:22, Andreas Fink wrote:
>> all latest compiled from these sources:
> 
> It looks like someone at Apple broke blocks on all ELF platforms a couple of 
> weeks ago.  It's not been merged to the 7 release branch though, so building 
> from that should fix things for you.
> 
> David
> 



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-08-31 Thread David Chisnall


On 31/08/2018 09:22, Andreas Fink wrote:

all latest compiled from these sources:


It looks like someone at Apple broke blocks on all ELF platforms a 
couple of weeks ago.  It's not been merged to the 7 release branch 
though, so building from that should fix things for you.


David


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-08-31 Thread Andreas Fink

all latest compiled from these sources:

git clone https://git.llvm.org/git/llvm.git/
cd llvm/tools
git clone https://git.llvm.org/git/clang.git/
cd ../projects
git clone https://git.llvm.org/git/compiler-rt.git/
git clone https://git.llvm.org/git/openmp.git/
git clone https://git.llvm.org/git/libcxx.git/
git clone https://git.llvm.org/git/libcxxabi.git/
git clone https://git.llvm.org/git/test-suite.git/
git clone https://git.llvm.org/git/lld.git/ 

wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.15.tar.gz
git clone https://github.com/apple/swift-corelibs-libdispatch
git clone https://github.com/gnustep/scripts
git clone https://github.com/gnustep/make
git clone https://github.com/gnustep/libobjc2
git clone https://github.com/gnustep/base
git clone https://github.com/gnustep/corebase
git clone https://github.com/gnustep/gui
git clone https://github.com/gnustep/back 

clang compiled with these options

cmake .. -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=lld 


these environment variables are set

export CC=/usr/local/bin/clang
export CXX=/usr/local/bin/clang++
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/
export LD=ld.lld


libdispatch:
cmake .. -DCMAKE_C_COMPILER=/usr/local/bin/clang 
-DCMAKE_CXX_COMPILER=/usr/local/bin/clang++ -DCMAKE_LINKER=/usr/local/bin/ld.lld

gnustep-make:
./configure --with-layout=fhs \
--disable-importing-config-file \
--enable-native-objc-exceptions \
--enable-objc-arc \
--enable-install-ld-so-conf \
--with-library-combo=ng-gnu-gnu \
--with-config-file=/usr/local/etc/GNUstep/GNUstep.conf \

libobjc2:
cmake .. -DBUILD_STATIC_LIBOBJC=1 
-DCMAKE_C_COMPILER=/usr/local/bin/clang 
-DCMAKE_CXX_COMPILER=/usr/local/bin/clang++ -DCMAKE_LINKER=/usr/local/bin/ld.lld


gnustep-base:
./configure --with-config-file=/usr/local/etc/GNUstep/GNUstep.conf 

if I add --disable-libdispatch --disable-mixedabi here it compiles but then the 
error appears in my own code as well when blocks are used.




> On 31 Aug 2018, at 10:15, David Chisnall  wrote:
> 
> Hi Andreas,
> 
> What runtime version are you targeting and what compiler are you using? It 
> appears that the block descriptor is including a full type encoding without 
> mangling it, which doesn't work on most ELF platforms because the @ symbol is 
> used as a separator between symbol name and version.
> 
> David
> 
> On 30/08/2018 22:22, Andreas Fink wrote:
>> anyone having a hint where this is coming from:
>> [root@localhost base]# make install
>> This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
>> Running in gnustep-make version 2 strict mode.
>> Making all in Source ...
>> Making all in Additions ...
>> Making all for subproject Additions...
>> make[4]: Nothing to be done for 'internal-subproject-compile'.
>> Making all in subprojects of library libgnustep-base...
>> Making all for subproject Additions...
>> make[5]: Nothing to be done for 'internal-subproject-compile'.
>> Making all for subproject unix...
>> make[5]: Nothing to be done for 'internal-subproject-compile'.
>> Making all for library libgnustep-base...
>>  Linking library libgnustep-base ...
>> */usr/bin/ld: ./obj/libgnustep-base.so.1.25.1: version node not found for 
>> symbol __block_descriptor_40_e8_32r_e15_v32@?0@8Q16^C24l*
>> /usr/bin/ld: failed to set dynamic section sizes: Bad value
>> clang-8: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> /usr/local/share/GNUstep/Makefiles/Instance/library.make:293: recipe for 
>> target 'obj/libgnustep-base.so.1.25.1' failed
>> make[4]: *** [obj/libgnustep-base.so.1.25.1] Error 1
>> /usr/local/share/GNUstep/Makefiles/Instance/library.make:278: recipe for 
>> target 'internal-library-all_' failed
>> make[3]: *** [internal-library-all_] Error 2
>> /usr/local/share/GNUstep/Makefiles/Master/rules.make:297: recipe for target 
>> 'libgnustep-base.all.library.variables' failed
>> make[2]: *** [libgnustep-base.all.library.variables] Error 2
>> /usr/local/share/GNUstep/Makefiles/Master/library.make:37: recipe for target 
>> 'internal-all' failed
>> make[1]: *** [internal-all] Error 2
>> /usr/local/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53: 
>> recipe for target 'internal-all' failed
>> make: *** [internal-all] Error 2
>> ___
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
> 

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

2018-08-31 Thread David Chisnall


Hi Andreas,

What runtime version are you targeting and what compiler are you using? 
It appears that the block descriptor is including a full type encoding 
without mangling it, which doesn't work on most ELF platforms because 
the @ symbol is used as a separator between symbol name and version.


David

On 30/08/2018 22:22, Andreas Fink wrote:

anyone having a hint where this is coming from:


[root@localhost base]# make install
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all in Source ...
Making all in Additions ...
Making all for subproject Additions...
make[4]: Nothing to be done for 'internal-subproject-compile'.
Making all in subprojects of library libgnustep-base...
Making all for subproject Additions...
make[5]: Nothing to be done for 'internal-subproject-compile'.
Making all for subproject unix...
make[5]: Nothing to be done for 'internal-subproject-compile'.
Making all for library libgnustep-base...
  Linking library libgnustep-base ...
*/usr/bin/ld: ./obj/libgnustep-base.so.1.25.1: version node not found 
for symbol __block_descriptor_40_e8_32r_e15_v32@?0@8Q16^C24l*

/usr/bin/ld: failed to set dynamic section sizes: Bad value
clang-8: error: linker command failed with exit code 1 (use -v to see 
invocation)
/usr/local/share/GNUstep/Makefiles/Instance/library.make:293: recipe for 
target 'obj/libgnustep-base.so.1.25.1' failed

make[4]: *** [obj/libgnustep-base.so.1.25.1] Error 1
/usr/local/share/GNUstep/Makefiles/Instance/library.make:278: recipe for 
target 'internal-library-all_' failed

make[3]: *** [internal-library-all_] Error 2
/usr/local/share/GNUstep/Makefiles/Master/rules.make:297: recipe for 
target 'libgnustep-base.all.library.variables' failed

make[2]: *** [libgnustep-base.all.library.variables] Error 2
/usr/local/share/GNUstep/Makefiles/Master/library.make:37: recipe for 
target 'internal-all' failed

make[1]: *** [internal-all] Error 2
/usr/local/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53: 
recipe for target 'internal-all' failed

make: *** [internal-all] Error 2

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep




___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

make fails in gnustep base

2018-08-30 Thread Andreas Fink

anyone having a hint where this is coming from:


[root@localhost base]# make install
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all in Source ...
Making all in Additions ...
Making all for subproject Additions...
make[4]: Nothing to be done for 'internal-subproject-compile'.
Making all in subprojects of library libgnustep-base...
Making all for subproject Additions...
make[5]: Nothing to be done for 'internal-subproject-compile'.
Making all for subproject unix...
make[5]: Nothing to be done for 'internal-subproject-compile'.
Making all for library libgnustep-base...
 Linking library libgnustep-base ...
/usr/bin/ld: ./obj/libgnustep-base.so.1.25.1: version node not found for symbol 
__block_descriptor_40_e8_32r_e15_v32@?0@8Q16^C24l
/usr/bin/ld: failed to set dynamic section sizes: Bad value
clang-8: error: linker command failed with exit code 1 (use -v to see 
invocation)
/usr/local/share/GNUstep/Makefiles/Instance/library.make:293: recipe for target 
'obj/libgnustep-base.so.1.25.1' failed
make[4]: *** [obj/libgnustep-base.so.1.25.1] Error 1
/usr/local/share/GNUstep/Makefiles/Instance/library.make:278: recipe for target 
'internal-library-all_' failed
make[3]: *** [internal-library-all_] Error 2
/usr/local/share/GNUstep/Makefiles/Master/rules.make:297: recipe for target 
'libgnustep-base.all.library.variables' failed
make[2]: *** [libgnustep-base.all.library.variables] Error 2
/usr/local/share/GNUstep/Makefiles/Master/library.make:37: recipe for target 
'internal-all' failed
make[1]: *** [internal-all] Error 2
/usr/local/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53: recipe 
for target 'internal-all' failed
make: *** [internal-all] Error 2___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

Re: make fails in gnustep base

make fails in gnustep base

12 matches

Site Navigation

Mail list logo

Footer information