Build fails on Cray: attempted static link of dynamic object

[daboehme]

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

[DavidPoliakoff]

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.

[daboehme]

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 <notifications@github.com> Reply-To: LLNL/GOTCHA <reply@reply.github.com> Date: Monday, July 3, 2017 at 2:22 PM To: LLNL/GOTCHA <GOTCHA@noreply.github.com> Cc: "Boehme, David" <boehme3@llnl.gov>, Author <author@noreply.github.com> 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 GitHub<#41 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKSk2OhDbOCwCqGQsSQIQHvuvQhh4V92ks5sKVt9gaJpZM4OMq5V>.

[DavidPoliakoff]

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.

[mplegendre]

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.

[DavidPoliakoff]

@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?

[daboehme]

Essentially it shouldn't fail using a default config / build on Cray. I tried it on Cori.

[DavidPoliakoff]

Cool, I'll see if I can get Cori access and go from there. Appreciate it!