Opened 10 years ago

Last modified 10 years ago

#7647 new Bugs

b2 incompatible with _STLP_LIB_NAME_MOTIF in stlport (no library names flexibility) - fatal error LNK1181: cannot open input file 'stlportstld.5.2.lib

Reported by: Marcello Pietrobon <marcello.pietrobon@…> Owned by: Vladimir Prus
Milestone: To Be Determined Component: build
Version: Boost 1.52.0 Severity: Problem
Keywords: b2 bjam stlport Cc:

Description

B2 seems too rigid with the searched libraries names used for stlport. It causes problems for someone who needs to use names a suffix _STLP_LIB_NAME_MOTIF that is not empty (see stlport/stl/config/user-config.h).

Here I explain the context the context. I've tried (succcessfully) to build boost_1_52 with stlport.5.2.1 with Microsoft vs 2010 (vc10)

I've essentially used what suggested in http://www.lenholgate.com/blog/2010/07/stlport-521-and-vs2010-and-x64.html.
The author of the pages uses _STLP_LIB_NAME_MOTIF in order to specify the compiler's name in the library name, which is what I need too.

To build with stlport I've followed the usual procedure:

1- added in tools/build/v2/user-config.jam the lines

using msvc : 10.0 ; using stlport : 5.2.1 : <my_path_to_stlport>/STLport-5.2.1/stlport : <my_path_to_stlport>/STLport-5.2.1/lib/vc10 ;

2- and issued the command:
.\tools\build\v2\b2.exe stdlib=stlport-5.2.1 toolset=msvc-10.0 debug/define=_STLP_DEBUG release --build-type=complete stage

What I get is a linking error to the stlport libraries when doing link=shared threading=multi (for example with --with-system)
the message error is: LINK : fatal error LNK1181: cannot open input file 'stlportstld.5.2.lib'

This is because stlport.jam ((probably this jam file) forces the link to the stlport with its own names, therefore bypassing what is specified in the file STLport-5.2.1\stlport\stl\config\_auto_link.h

I wonder why this choice, considering that life was beautiful years ago when this everything was delegated to stlport\stl\config\_auto_link.h. I imagine you had your own reasons.



Things therefore work if I do:

tools/build/v2/user-config.jam:

using msvc : 10.0 ; using stlport : vc10.5.2.1 : <my_path_to_stlport>/STLport-5.2.1/stlport : <my_path_to_stlport>/STLport-5.2.1/lib/vc10 ;

and issue the command:

.\tools\build\v2\b2.exe stdlib=stlport-vc10.5.2.1 toolset=msvc-10.0 debug/define=_STLP_DEBUG release --build-type=complete stage

But still there is one strange behaviour which is problematic.

Let's take tools/build/v2/user-config.jam again

with

using stlport : 5.2.1 : ....
the library searched was stlportstld.5.2.lib


with

using stlport : vc10.5.2.1 : ....
the library searched was stlportstldvc10.5.2.lib


with

using stlport : xyz.5.2.1 : ....
the library searched was stlportstldvc10.5.2.lib i.e. not stlportstldxyz.5.2.lib

And this is a problem, as people may want to build to the stlport libraries also when their name name is modified according to the _STLP_LIB_NAME_MOTIF macro in stlport/stl/config/user-config.h. Hope this will be fixed, if you agree this is a limitation. Again, I wish everything would be left to what is specified in STLport-5.2.1\stlport\stl\config\_auto_link.h

Change History (2)

comment:1 by Marcello Pietrobon <marcello.pietrobon@…>, 10 years ago

I have checked again this ticket I made and actually I see that the statement I made:
This is because stlport.jam ((probably this jam file) forces the link to the stlport with its own names, therefore bypassing what is specified in the file STLport-5.2.1\stlport\stl\config\_auto_link.h
is not true.

I made a different change in STLport-5.2.1\stlport\stl\config\_auto_link.h and things work fine now.

I still find there is something puzzling with a jam file (stlport.jam?), because it's still true the part that I wrote above that I'm repeating here:

with
using stlport : 5.2.1 : ....
the library searched was stlportstld.5.2.lib

with
using stlport : vc10.5.2.1 : ....
the library searched was stlportstldvc10.5.2.lib

with
using stlport : xyz.5.2.1 : ....
the library searched was stlportstldvc10.5.2.lib i.e. not stlportstldxyz.5.2.lib 

Unfortunately I don't have time to further investigate the reason of this behaviour. Thanks.

comment:2 by viboes, 10 years ago

Component: Building Boostbuild
Owner: set to Vladimir Prus
Note: See TracTickets for help on using tickets.