gtest linking warnings with static builds on cray systems

[cyrush]

../../lib/libgtest.a(gtest-all.cc.o): In function `testing::internal::StreamingListener::SocketWriter::MakeConnection()':
gtest-all.cc:(.text+0x3af47): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[ 4%] Built target blt_gtest_smoke

[cyrush]

On Cray, setting the following env var:

export CRAYPE_LINK_TYPE=dynamic

Eliminates these warnings.

I think this might be a good-enough solution.

[zbeekman]

It may achieve the same effect, but the wrappers (cc, CC, ftn) also accept a -dynamic flag. It may have an identical effect.

[cyrush]

awesome, we can try to provide those as defaults for cray compiler wrappers. Although I don't think we identify the cray compiler wrappers yet.

[zbeekman]

Just FYI, Cray typically prefers to compile things statically (in my experience) so there should probably be some control left to the user as to whether or not to pass -dynamic

On Wed, Nov 15, 2017 at 5:36 PM Cyrus Harrison [email protected] wrote:

awesome, we can try to provide those as defaults for cray compiler wrappers. Although I don't think we identify the cray compiler wrappers yet.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LLNL/blt/issues/94#issuecomment-344776563, or mute the thread https://github.com/notifications/unsubscribe-auth/AAREPAZ3dLrfoKwPMezHAXGUCg3b4zMDks5s24OPgaJpZM4PeMPl .

[cyrush]

Good point -- these cases are actually where we want to create static libs, but some of the deps (gtest in this case, and things like hdf5 in others) have dlopens, etc that we can't avoid, so we have to link to the shared runtime.

So I agree -- maybe we don't default to adding the flag, but if we could direct the compiler wrappers (or even the just that we are on a cray) it would make it easier for projects to add them when necessary.