Re: make fails in gnustep base

[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 <afink@list.fink.org> 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
> 
> <test2.tar.gz>
> 
> 
> 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.934894444458547e-310
> _int9=99
> _string10=s1010
> 
> 
> 
>> On 4 Sep 2018, at 07:37, Andreas Fink <afink@list.fink.org> wrote:
>> 
>> 
>> 
>>> On 3 Sep 2018, at 23:40, Ivan Vučica <ivan@vucica.net> 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