GOTCHA
GOTCHA copied to clipboard
Build fails on Cray: attempted static link of dynamic object
Build fails on platforms that prefer static linking, here Cray:
Linking C executable autotee_test
cd /global/homes/b/boehme3/src/GOTCHA/build-cori/src/example/autotee && /usr/bin/cmake -E cmake_link_script CMakeFiles/autotee_test.dir/link.txt --verbose=1
/opt/cray/pe/craype/2.5.7/bin/cc CMakeFiles/autotee_test.dir/test_autotee.c.o -o autotee_test -rdynamic libautotee.so ../../libgotcha.so.0.0.1 -Wl,-rpath,/global/homes/b/boehme3/src/GOTCHA/build-cori/src/example/autotee:/global/homes/b/boehme3/src/GOTCHA/build-cori/src
/usr/bin/ld: attempted static link of dynamic object 'libautotee.so'
src/example/autotee/CMakeFiles/autotee_test.dir/build.make:90: recipe for target 'src/example/autotee/autotee_test' failed
make[2]: *** [src/example/autotee/autotee_test] Error 1
Since it's you, I wanted to try something
Could you set the environment variables
export XTPE_LINK_TYPE=dynamic
export CRAYPE_LINK_TYPE=dynamic
Before building? If that works, I'll push a fix in GOTCHA.
That works for the gotcha build, but does this have additional effects? E.g. if you want to build Caliper statically?
David
From: David Poliakoff [email protected] Reply-To: LLNL/GOTCHA [email protected] Date: Monday, July 3, 2017 at 2:22 PM To: LLNL/GOTCHA [email protected] Cc: "Boehme, David" [email protected], Author [email protected] Subject: Re: [LLNL/GOTCHA] Build fails on Cray: attempted static link of dynamic object (#41)
Since it's you, I wanted to try something
Could you set the environment variables
export XTPE_LINK_TYPE=dynamic
export CRAYPE_LINK_TYPE=dynamic
Before building? If that works, I'll push a fix in GOTCHA.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/LLNL/GOTCHA/issues/41#issuecomment-312735854, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKSk2OhDbOCwCqGQsSQIQHvuvQhh4V92ks5sKVt9gaJpZM4OMq5V.
I'll need to test it. For now I'm centered around getting GOTCHA not to shoot itself in the foot this way, I think I can make it just build me shared. I don't know what happens if GOTCHA is built shared and you're built static yet. Obviously you can't redirect functions from libcaliper(.a), but you should be able to redirect from libpthread to a function inside yourself, but I need to make very sure of that. You're an endless font of test cases, thanks, this should make the software stronger.
Off the top of my head, I don't see why we shouldn't be able to make gotcha a static library (though it should still be compiled -fPIC) so that it can be linked directly into another tool library. But to be clear, it absolutely will not work with a statically-linked binary. Gotcha works by modifying the dynamic-linker data structures that are only present in dynamically-linked binaries.
The day may come where gotcha has some support for static binaries, but it will be a completely different implementation.
@daboehme , how would you recommend replicating this issue? Is there a Cray machine you'd like to see this work on? A Caliper build line?
Essentially it shouldn't fail using a default config / build on Cray. I tried it on Cori.
Cool, I'll see if I can get Cori access and go from there. Appreciate it!