Re: [Boost-build] link switches

Subject: Re: [Boost-build] link switches
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-11-13 00:20:07

On 11/12/17 3:15 PM, Edward Diener via Boost-build wrote:
> On 11/12/2017 5:35 PM, Robert Ramey via Boost-build wrote:
>> On 11/12/17 2:14 PM, Steven Watanabe via Boost-build wrote:

> For the "run' rule the designation "sources" means whatever files are 
> needed to build the final executable. The designation "input-files" 
> means command line parameters as the names of files passed to the final 
> executable on the command line when the program is run, or executed.
> 
> Since it was you who wrote the "test-bsl-run' rule, which eventually 
> causes the Boost Build 'run' rule to be invoked, shouldn't you yourself 
> know what the parameters to your own rule means ?

these are parameters to the run rule which I use.  But I didn't write 
it. I'm just a user of it.

But now that you've been sucked into the discussion, what about this:

in my test code I have the following statement:

     void * hDLL;               // Handle to DLL
     hDLL = dlopen("polymorphic_derived2.so", RTLD_NOW | RTLD_GLOBAL);
     BOOST_CHECK_MESSAGE((0 != hDLL), "Failed to find/load 
plugin_polymorphic_derived2" );
     BOOST_CHECK_MESSAGE((0 != hDLL), dlerror() );

Which displays the messages

test_dll_plugin.cpp(196): Failed to find/load 
plugin_polymorphic_derived2 in function 'int test_main(int, char**)'

test_dll_plugin.cpp(197): polymorphic_derived2.so: cannot open shared 
object file: No such file or directory in function 'int test_main(int, 
char**)'

This code is meant to dynamically load the shared object named 
"polymorphic_derived2.so"

It can't seem to find the shared object file named 
"polymorphic_derived2.so".  OK so I went looking for it.  I found the 
following:

parallels_at_ubuntu:/media/psf/Home/WorkingProjects/modular-boost/bin.v2/libs/serialization/test$ 
ls */*/*.so*

gcc-gnu-4.8/debug/libpolymorphic_derived2.so.1.66.0
gcc-gnu-4.8/release/libpolymorphic_derived2.so.1.66.0

which look to be the correct files several directory levels above the 
tests. They also have unexpected names.  How is my test program supposed 
to find these?  What should I do differently?

Robert Ramey