Re: [Boost-build] library naming under Windows 64 bit compiler

Subject: Re: [Boost-build] library naming under Windows 64 bit compiler
From: Ian Emmons (iemmons_at_[hidden])
Date: 2009-08-25 10:34:08

A related question:  When I compile the Boost libraries using the  
stage target, I get a single directory full of files with names like  
these:

boost_unit_test_framework-vc90-mt-gd-1_38.dll
boost_unit_test_framework-vc90-mt-1_38.dll
boost_unit_test_framework-vc80-mt-gd-1_38.dll
boost_unit_test_framework-vc80-mt-1_38.dll

These names have discriminators for the specific compiler and version,  
whether the library is a debug version, whether compiled for multi- 
threaded code, and the specific version of Boost.  However, there is  
no discriminator for the address model and architecture.  As a result,  
I have to manually go to some effort to keep a set of 32-bit libraries  
separate from a set of 64-bit ones.  It took me quite a long time to  
figure out how to do this the first time, and so I suspect that this  
is a significant barrier to adoption of Boost.

On Macintosh, things are potentially messier as there are several  
combinations of address model and architecture that one might need to  
maintain (although anyone who can use the "architecture=combined" and  
"address-model=32_64" features can avoid this complication entirely).

Is this list the proper place to discuss whether discriminators for  
address-model and architecture could be added to the Boost libraries  
build, or should that be discussed elsewhere?

Thanks,

Ian

On Aug 25, 2009, at 1:50 AM, Vladimir Prus wrote:
> On Monday 24 August 2009 Mike Jackson wrote:
>> Using VS 2008 Standard Edition and the VS x64 command prompt I
>> configured boost 1.39 using the "address-model=64" option to get 64
>> bit binaries. All seemed to work except that the naming of the
>> libraries are:
>>
>> libboost_filesystem-vc-mt-1_39.lib
>>
>> Usually I would see:
>>
>> libboost_filesystem-vc90-mt-1_39.lib  using a 32 bit command prompt
>> under VS2008 and Windows XP. What's up?
>
> Please add the --debug-configuration option, provide the exact  
> command line
> after that addition, and the output that is produced. This should be
> enough to diagnose this.
>
> Thanks,
> Volodya