Re: [Boost-build] [EXTERNAL] cflags not being inherited

Subject: Re: [Boost-build] [EXTERNAL] cflags not being inherited
From: Paulo Márcio Figueiredo Alves (pauloalves1986_at_[hidden])
Date: 2014-03-10 14:53:49

On Fri, Feb 21, 2014 at 2:47 AM, Vladimir Prus <ghost_at_[hidden]> wrote:

> On 19.02.2014 17:57, Paulo Márcio Figueiredo Alves wrote:
>
>> I have made a simple test to show the problem (attached file). If you do
>> not use Boost.Thread, the problem does not occur.
>> Adjust boost path (line 1) and call b2 -a, you'll see "recompile with
>> -fPIC". Choose one of the commented choices
>> for target foo_static and you will see that there is no way to make it
>> work, unless you call b2 -a cxxflags=-fPIC.
>>
>> Is it a bug? Is there any workaround? Am I doing something wrong?
>>
>
> Paulo,
>
> the issue here is that <cflags> is not passed through like this, we need
> to either make them passed, or issue
> an error.
>
> Anyway, the most immediate solution would be something like:
>
>         feature.feature fpic : off on : composite ;
>
>         feature.compose <fpic>on : <cflags>-fPIC <cxxflags>-fPIC ;
>
> and use <fpic>on
>
> Does this help?
>

No, the error persists. The only solutions so far is pass cxxflags=-fPIC in
command line.
The solution proposed by Thomas Suckow does not work as well.
Any idea how to solve this? Where can I investigate (jam or c file) the
problem?

Thank you
Paulo Marcio

>
> - Volodya
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost-build
>
>

On Thu, Feb 20, 2014 at 11:56 AM, Paulo Márcio Figueiredo Alves <
pauloalves1986_at_[hidden]> wrote:

> Thank you for the tips, /boost//headers is very useful and I was looking
> forward to something like that.
>
> The problem is my shared libraries are not used like:
> exe foo : foo.cc foo_shared : <threading>multi ;
>
> I use them with dlopen and LoadLibrary, and it drivers me to another
> chalenge, create the simplest
> build working on Windows, Linux and MacOS. On Windows I am not able to
> create a DLL with this:
>
> *lib foo_shared : foo_shared.cc foo_static : <link>shared  : :
> <library>/boost//thread/<link>static ;*
>
> because gives me that:
>
> libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
> symbol "class boost::system::error_category const & __cdecl
> boost::system::system_category(void)" (?system_category_at_system@boost@
> @YAABVerror_category_at_12@XZ) referenced in function "public: __thiscall
> boost::thread_exception::thread_exception(int,char const *)"
> (??0thread_exception_at_boost@@QAE_at_HPBD@Z)
> libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
> symbol "class boost::system::error_category const & __cdecl
> boost::system::generic_category(void)" (?generic_category_at_system@boost@
> @YAABVerror_category_at_12@XZ) referenced in function "void __cdecl
> boost::system::`dynamic initializer for 'errno_ecat''(void)"
> (??__Eerrno_ecat_at_system@boost@@YAXXZ)
> libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
> symbol "public: __thiscall boost::thread::thread(void)" (??0thread_at_boost
> @@QAE_at_XZ) referenced in function "int __cdecl foo_static(void)"
> (?foo_static@@YAHXZ)
> libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
> symbol "public: void __thiscall boost::thread::detach(void)" (?detach_at_thread
> @boost@@QAEXXZ) referenced in function "public: __thiscall
> boost::thread::~thread(void)" (??1thread_at_boost@@QAE_at_XZ)
> bin\msvc-12.0\debug\foo_shared.dll : fatal error LNK1120: 4 unresolved
> externals
>
> so I have to use:
>
> *lib foo_shared : foo_shared.cc foo_static : <link>shared
> <library>/boost//thread/<link>static : :
> <library>/boost//thread/<link>static ;*
>
> or use *<target-os>windows:<library>/boost//thread/<link>static *and
> solve Windows and Linux
> in an ugly way. I just don't know the best approach, and I think
> <cxxflags>-fPIC should be
> inherited regardless anything else. With this flags not being inherited, I
> have other problems
> like using <cxxflags>-std=c++11 and Boost.Filesystem generates "undefined
> reference" under Linux.
>
> What you think? Is there any workaround, maybe force inheritance?
>
>
> Thank you
>
>
> On Wed, Feb 19, 2014 at 7:59 PM, Thomas Suckow <thomas.suckow_at_[hidden]>wrote:
>
>> On 02/19/2014 11:33 AM, Paulo Márcio Figueiredo Alves wrote:
>>
>>> I have made a simple test to show the problem (attached file). If you do
>>> not use Boost.Thread, the problem does not occur.
>>> Adjust boost path (line 1) and call b2 -a, you'll see "recompile with
>>> -fPIC". Choose one of the commented choices
>>> for target foo_static and you will see that there is no way to make it
>>> work, unless you call b2 -a cxxflags=-fPIC.
>>>
>>> Is it a bug? Is there any workaround? Am I doing something wrong?
>>>
>>
>> It would appear that the override of <link>static is preventing
>> boost-build from knowing it needs to use -fPIC.
>>
>> That said, it bugs me thinking that the boost libraries are being linked
>> into more than one of your shared libraries.
>>
>> In your library, since random is header-only, I would use:
>> : <use>/boost//headers <implicit-dependency>/boost//headers ;
>> AFAIK, this is the most correct syntax. I've been trying to figure out
>> the best syntax since modular-boost changes some things.
>>
>> This is the best I could come up with:
>> lib foo_static : foo_static.cc : <link>static <cxxflags>-fPIC
>> <use>/boost//headers <implicit-dependency>/boost//headers ;
>>
>> lib foo_shared : foo_shared.cc foo_static : <link>shared  : :
>> <library>/boost//thread/<link>static ;
>>
>> exe foo : foo.cc foo_shared : <threading>multi ;
>>
>>
>> I am kind of disappointed in this solution :-/
>>
>>
>> -
>> Thomas
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/
>> mailman/listinfo.cgi/boost-build
>>
>
>