Fix multiple_translation_units test

[syclik]

Summary:

Multiple translation units test fails on Linux. This shouldn't fail.
See: http://discourse.mc-stan.org/t/stan-math-ubuntu-clang-needs-fpic/339/3

Description:

The test was originally put in place so we can check that the headers be included from multiple translation units and compiled separately. We've added inline to all our functions which allows this behavior.

It currently runs on Mac with the clang++ and g++ compilers, but this may not be safe with the compiler flags that are default for linux.

Possible fixes:

1. Remove the test and don't support including in multiple translation units. This originally came up with @rgiordan 's request; I'm not sure who else depends on this.
2. Fix the compiler options so it works for Linux (and Windows?). Looks like adding -fPIC may do it. See: http://discourse.mc-stan.org/t/stan-math-ubuntu-clang-needs-fpic/339/3

Reproducible Steps:

Run:
./runTests.py test/unit/multiple_translation_units_test.cpp

Current Output:

clang++ -shared -o test/unit/libmultiple.so test/unit/multiple_translation_units1.o test/unit/multiple_translation_units2.o
/usr/bin/ld: test/unit/multiple_translation_units1.o: relocation R_X86_64_32S against `_ZTVN4stan4math4variE' can not be used when making a shared object; recompile with -fPIC
test/unit/multiple_translation_units1.o: error adding symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Expected Output:

It runs.

Additional Information:

Thanks, Ben! (Sorry, don't know your GitHub profile)
@seantalts, mind helping out?

Current Version:

v2.15.0

[seantalts]

Does anyone know why we are testing multiple_translation_units with the -shared option instead of providing a main somewhere? I think if our intended use-case is for it to be compiled as a shared library, -fPIC is completely reasonable, and if not I can take out the -shared and add a main.

[syclik]

@seantalts, it came from @rgiordan's use case. See the original GitHub issue for history:
#328

There's no reason we need to have the -shared option. We can do it any other way. I think the goal is still worth trying to meet, but if it's too much trouble, we should just stop supporting it. (It being allowing the math library to be brought into multiple translation units.)

I think adding a main will break it? I'm not sure.

[seantalts]

Ah, okay. I think the -shared option might be important for the linked use-case (which is to have it all compiled as a shared library at the end of the day) so I will just add -fPIC to this test. -fPIC option seems pretty standard for a shared library.

[syclik]

Thanks!

…

On Mon, Apr 17, 2017 at 4:56 PM, seantalts ***@***.***> wrote: Ah, okay. I think the -shared option might be important for the linked use-case (which is to have it all compiled as a shared library at the end of the day) so I will just add -fPIC to this test. -fPIC option seems pretty standard for a shared library. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#522 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZ_FzSYPfczk_KT9ZocFwIkkZgdu4FUks5rw9INgaJpZM4M-0OZ> .

[rgiordan]

Thanks for fixing this! I do think the ability to use stan::math in multiple translation units is an important feature if it's to be a general-purpose autodifferentiation library for C++. Consider, for example, someone building a shared library to provide primitives for Bayesian non-parametric priors and someone else linking to that library with their own custom likelihood to generate data. If stan::math headers can't be included in multiple translation units, then both people can't use stan's auto differentiation features.