Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-09-19 15:09:35


On Tuesday 19 September 2006 22:18, John Maddock wrote:
> Just when I thought everything was sweetnes and light, up pops another one:
>
> Testing with Intel on Win32, the libraries are being named for example:
>
> Creating library
> ..\..\..\..\..\bin.v2\libs\config\test\link\test\intel-win-8
> .1\release\threading-multi\link_test-81-mt-1_35.lib and object
> ..\..\..\..\..\bi
> n.v2\libs\config\test\link\test\intel-win-8.1\release\threading-multi\link_
>test- 81-mt-1_35.exp
>
> So with a compiler-version-number, but without a "iw" toolset name.
>
> The autolink code expects the reverse: for example in this case it would be
> "link_test-iw-mt-1_35.lib".
>
> I believe the rationale for not versioning the intel toolset, is that what
> matters is the msvc compiler targeted, not the intel compiler version as
> far as binary compatibility is concerned, so basically bbv1 chickened out
> of versioning the toolset names, and the auto-link code followed.
>
> It would be easy enough to change the autolink code to accept names
> versioned on either the msvc version or the intel version, or - god
> forbid - both. But it would require some discussion on the Boost list to
> decide what the right thing to do is.
>
> Probably the easiest course of action, and one that won't hold up the 1.34
> release is to do what bbv1 did and add an "iw" toolset name with no
> compiler version number.

Done in CVS. Can you try again? I've removed version both in windows and
linux. Is that right?

>
> And finally, I hope :-) the borland compiler.
>
> I'm seeing a whole lot of errors along the lines of:
>
> Support for Borland compilers older than BCB2006 is deprecated in Boost
> 1.34 borland.archive
> ..\..\..\..\..\bin.v2\libs\config\test\link\test\borland\release
> \link-static\threading-multi\liblink_test-bcb-mt-1_35.lib
> TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
> Warning: 'link_test' not found in library
> borland.link
> ..\..\..\..\..\bin.v2\libs\config\test\link\test\link_test_dyn_mult
> i_release.test\borland\release\link-static\threading-multi\link_test_dyn_mu
>lti_r elease.exe
> Fatal: Unable to open file 'LIBLINK_TEST-BCB-MT-1_35.LIB'
>
> set "PATH=C:/cpp/Borland/CBuilder6/bin/;%PATH%"
> "C:/cpp/Borland/CBuilder6/Bin/bcc32.exe" -v -q -tWC -tWR -tWC -WM-
> -tWM -L"C:/cpp/Borland/CBuilder6/lib"
> -e"..\..\..\..\..\bin.v2\libs\config\test\link\
> test\link_test_dyn_multi_release.test\borland\release\link-static\threading
>-mult i\link_test_dyn_multi_release.exe"
> @"..\..\..\..\..\bin.v2\libs\config\test\link
> \test\link_test_dyn_multi_release.test\borland\release\link-static\threadin
>g-mul ti\link_test_dyn_multi_release.exe.rsp"
>
> It seems that the lib's are being named correctly (but I haven't checked
> them all), but the link fails because the directory that contains the lib
> isn't in the lib search path. Adding a -Lpath-to-lib on the command line
> would fix that.

What's in response file? I get absolute path to the library there, but doing
this on Linux I've no idea what you'd get on Windows.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2

Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk