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
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
> 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
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
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
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
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 -
*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:
>
>
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
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
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.
11 matches
Mail list logo
