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 <[email protected]> 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 <[email protected]> wrote: >> >> >> >>> On 3 Sep 2018, at 23:40, Ivan Vučica <[email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > _______________________________________________ > Discuss-gnustep mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
