make fails in gnustep base

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

make fails in gnustep base

Andreas Fink-2
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

David Chisnall-7
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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

Andreas Fink-2
all latest compiled from these sources:

cd llvm/tools
cd ../projects


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 <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

David Chisnall-7
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

Andreas Fink-2
*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 <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

Andreas Fink-2
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

David Chisnall-7
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

Andreas Fink-2
In reply to this post by David Chisnall-7
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 <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

Ivan Vučica-2
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

Andreas Fink-2


> On 3 Sep 2018, at 23:40, Ivan Vučica <[hidden email]> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

Andreas Fink-2

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.934894444458547e-310
 _int9=99
 _string10=s1010



> On 4 Sep 2018, at 07:37, Andreas Fink <[hidden email]> wrote:
>
>
>
>> On 3 Sep 2018, at 23:40, Ivan Vučica <[hidden email]> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

test2.tar.gz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: make fails in gnustep base

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



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep