32/64 library name conflict under Windows?
I remember that we discussed this problem before: C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0 address-model=32,64 [...] error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. but don't remember what we concluded. Will we support building both 32 and 64 bit libraries under Windows? At present if I want to have an IDE project that has both Win32 and x64 configurations I need to build the 32 bit libraries, move them out of stage/lib somewhere, then build the 64 bit libraries, then move them out of stage/lib to somewhere else, and set my library directories in the IDE accordingly. It would be much more convenient if 32/64 were encoded into the name, so that I can leave my library path to point at stage/lib and rely on autolink to choose the right .lib file automatically, like it works today for the other options (debug/release, static/dynamic runtime).
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 04 March 2016 18:32 To: boost-devel Subject: [boost] 32/64 library name conflict under Windows?
I remember that we discussed this problem before:
C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0 address-model=32,64
[...]
error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.
but don't remember what we concluded. Will we support building both 32 and 64 bit libraries under Windows? At present if I want to have an IDE project that has both Win32 and x64 configurations I need to build the 32 bit libraries, move them out of stage/lib somewhere, then build the 64 bit libraries, then move them out of stage/lib to somewhere else, and set my library directories in the IDE accordingly.
It would be much more convenient if 32/64 were encoded into the name, so that I can leave my library path to point at stage/lib and rely on autolink to choose the right .lib file automatically, like it works today for the other options (debug/release, static/dynamic runtime).
+1 (at least) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Mar 7, 2016, at 4:32 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 04 March 2016 18:32 To: boost-devel Subject: [boost] 32/64 library name conflict under Windows?
I remember that we discussed this problem before:
C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0 address-model=32,64
[...]
error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.
but don't remember what we concluded. Will we support building both 32 and 64 bit libraries under Windows? At present if I want to have an IDE project that has both Win32 and x64 configurations I need to build the 32 bit libraries, move them out of stage/lib somewhere, then build the 64 bit libraries, then move them out of stage/lib to somewhere else, and set my library directories in the IDE accordingly.
It would be much more convenient if 32/64 were encoded into the name, so that I can leave my library path to point at stage/lib and rely on autolink to choose the right .lib file automatically, like it works today for the other options (debug/release, static/dynamic runtime).
+1 (at least)
Paul
+1 for me as well.
On Fri, Mar 4, 2016 at 12:31 PM, Peter Dimov <lists@pdimov.com> wrote:
I remember that we discussed this problem before:
C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0 address-model=32,64
[...]
error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.
but don't remember what we concluded. Will we support building both 32 and 64 bit libraries under Windows? At present if I want to have an IDE project that has both Win32 and x64 configurations I need to build the 32 bit libraries, move them out of stage/lib somewhere, then build the 64 bit libraries, then move them out of stage/lib to somewhere else, and set my library directories in the IDE accordingly.
It would be much more convenient if 32/64 were encoded into the name, so that I can leave my library path to point at stage/lib and rely on autolink to choose the right .lib file automatically, like it works today for the other options (debug/release, static/dynamic runtime).
1. Some people don't fancy auto-linking. 2. People responding with "+N".. Which of the following would you prefer? And give rationale for your preference, and optionally give rationales for not preferring others: A) Having file names with "32" *and* "64" on them? B) Having current names indicate 32 and adding "64" to file names otherwise? C) Having current names indicate the "default" system address-model and add "32" or "64" to indicate the non-default? D) Having the current names and placing 32 bit address-model variants in "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location) E) Having the current names and placing 32 bit address-model variants in "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location) F) Having the current names and placing the "default" system address-model variants in "stage/lib" and the non-default in "stage/lib32" or "stage/lib64"? (Equivalently for install location) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 2016-03-08 6:18 AM, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
2. People responding with "+N".. Which of the following would you prefer? And give rationale for your preference, and optionally give rationales for not preferring others:
A) Having file names with "32" *and* "64" on them?
B) Having current names indicate 32 and adding "64" to file names otherwise?
C) Having current names indicate the "default" system address-model and add "32" or "64" to indicate the non-default?
D) Having the current names and placing 32 bit address-model variants in "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)
E) Having the current names and placing 32 bit address-model variants in "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location)
F) Having the current names and placing the "default" system address-model variants in "stage/lib" and the non-default in "stage/lib32" or "stage/lib64"? (Equivalently for install location)
I would prefer option A. It fits current naming scheme where each available option is spelled out explicitly as part of the name: toolset, thread_opt, rt_opt. This would just add another option to this list: platform(x86, x64, arm). There is another alternative, which will suit better people who don't fancy auto-linking: use the composed name for folder and keep library names the same: vc140-x86-mt-1_60/ boost_system.lib boost_thread.lib ... vc140-x64-mt-1_60/ boost_system.lib boost_thread.lib ... Auto-linking would work exactly as it works now, but for people configuring projects manually things will become much easier: specify the same library names for all targets, just a different folder to look for libraries per each target. This would become even better if option names were to correspond to relevant toolset macro names. Than one could also specify the same lib folder for all targets: boost_1_60_0/lib/$(PlatformToolset)-$(PlatformTarget)-mt-$(Configuration)-1_60/ This would expand into: boost_1_60_0/lib/vc140-x64-mt-Debug-1_60/ boost_1_60_0/lib/vc140-x86-mt-Release-1_60/ etc.
On March 8, 2016 2:36:42 AM EST, Boris Rasin <boris@pointx.org> wrote:
On 2016-03-08 6:18 AM, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
It doesn't play well for cross-platform development since linking is treated entirely differently. Otherwise, there's a lot to like.
2. People responding with "+N".. Which of the following would you prefer?
I didn't respond earlier, but I will do so now.
And give rationale for your preference, and optionally give rationales for not preferring others:
A) Having file names with "32" *and* "64" on them?
This is useful to avoid confusion, but it should be generalized to architecture to account for more than just bit width.
B) Having current names indicate 32 and adding "64" to file names otherwise?
That leaves room for ambiguity, so I don't like it.
C) Having current names indicate the "default" system address-model and add "32" or "64" to indicate the non-default?
That leaves room for confusion as to the default, especially as it could vary with OS.
D) Having the current names and placing 32 bit address-model variants in "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)
This has appeal as it means one need only change the library search path. However, once the libraries have been copied out of those directories, one must inspect the binary to know what they are.
E) Having the current names and placing 32 bit address-model variants in "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location)
That's in keeping with the Linux model. Following precedent isn't a bad thing. Otherwise it has the same benefits and problems as D.
F) Having the current names and placing the "default" system address-model variants in "stage/lib" and the non-default in "stage/lib32" or "stage/lib64"? (Equivalently for install location)
I don't like the "default" notion.
I would prefer option A. It fits current naming scheme where each available option is spelled out explicitly as part of the name: toolset, thread_opt, rt_opt. This would just add another option to this list: platform(x86, x64, arm).
+1
There is another alternative, which will suit better people who don't fancy auto-linking: use the composed name for folder and keep library names the same:
vc140-x86-mt-1_60/ boost_system.lib boost_thread.lib ...
vc140-x64-mt-1_60/ boost_system.lib boost_thread.lib ...
Auto-linking would work exactly as it works now, but for people configuring projects manually things will become much easier: specify the same library names for all targets, just a different folder to look for libraries per each target.
If the libraries are copied elsewhere, the distinction is lost. Despite the benefits you note, I think that's undesirable.
This would become even better if option names were to correspond to relevant toolset macro names. Than one could also specify the same lib folder for all targets:
boost_1_60_0/lib/$(PlatformToolset)-$(PlatformTarget)-mt-$(Configuration)-1_60/
This would expand into:
boost_1_60_0/lib/vc140-x64-mt-Debug-1_60/ boost_1_60_0/lib/vc140-x86-mt-Release-1_60/ etc.
I like all of that, just not the non-unique names that result. ___ Rob (Sent from my portable computation engine)
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: 08 March 2016 04:19 To: boost@lists.boost.org Subject: Re: [boost] 32/64 library name conflict under Windows?
On Fri, Mar 4, 2016 at 12:31 PM, Peter Dimov <lists@pdimov.com> wrote:
I remember that we discussed this problem before:
C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0 address-model=32,64
[...]
error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.
but don't remember what we concluded. Will we support building both 32 and 64 bit libraries under Windows? At present if I want to have an IDE project that has both Win32 and x64 configurations I need to build the 32 bit libraries, move them out of stage/lib somewhere, then build the 64 bit libraries, then move them out of stage/lib to somewhere else, and set my library directories in the IDE accordingly.
It would be much more convenient if 32/64 were encoded into the name, so that I can leave my library path to point at stage/lib and rely on autolink to choose the right .lib file automatically, like it works today for the other options (debug/release, static/dynamic runtime).
1. Some people don't fancy auto-linking.
Excellent (when it works - almost always).
2. People responding with "+N".. Which of the following would you prefer? And give rationale for your preference, and optionally give rationales for not preferring others:
A) Having file names with "32" *and* "64" on them?
Explicit is good. Follows current scheme of having different unique names for different variants. Once started unique names, we should continue.
B) Having current names indicate 32 and adding "64" to file names otherwise?
Acceptable.
C) Having current names indicate the "default" system address-model and add "32" or "64" to indicate the non-default?
KISS
D) Having the current names and placing 32 bit address-model variants in "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)
Having two files with same name in different folders is less explicit than two different filenames.
E) Having the current names and placing 32 bit address-model variants in "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location)
Make be less trouble short term, but less clear when 64 becomes the default? (and what about 128-bit ;-)
F) Having the current names and placing the "default" system address-model variants in "stage/lib" and the non-default in "stage/lib32" or "stage/lib64"? (Equivalently for install location)
KISS (https://en.wikipedia.org/wiki/KISS_principle is *my* default position). So I favour option A. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 8 March 2016 at 11:45, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
KISS (https://en.wikipedia.org/wiki/KISS_principle is *my* default position).
So I favour option A.
I agree. I've been annoyed by this issue for years (because tools like Cmake can't automatically find which version to link because Boost doesn't give a default logic to find which arch are these binaries). Last time there was a discussion, most people agreed something should be done but there was no concensus on what to do exactly (nor was there a specific proposal). Joël Lamotte
On 2016-03-08 07:18, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
2. People responding with "+N".. Which of the following would you prefer?
I wasn't responding before but let me add my references.
And give rationale for your preference, and optionally give rationales for not preferring others:
A) Having file names with "32" *and* "64" on them?
This would be an ok solution, although not the best.
B) Having current names indicate 32 and adding "64" to file names otherwise?
Please no. This makes the current names ambiguous to someone not familiar with the convention. And why the 32-bit version should be the default?
C) Having current names indicate the "default" system address-model and add "32" or "64" to indicate the non-default?
No. This ties naming with the default in Boost.Build, which hopefully will change to 64-bit at some point.
D) Having the current names and placing 32 bit address-model variants in "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)
Out of the proposed variants, this one I like the most.
E) Having the current names and placing 32 bit address-model variants in "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location)
No. Same argument as for B.
F) Having the current names and placing the "default" system address-model variants in "stage/lib" and the non-default in "stage/lib32" or "stage/lib64"? (Equivalently for install location)
No. Same argument as for C. I think another option is missing here, and I would like this option the most: G) Put libraries to a subdirectory named according to the architecture, e.g. "stage/i686", "stage/x86_64", "stage/armhf", etc. I'm not sure how install target works on Windows, but the target install directories should also correspond to the architecture of the binaries. This would solve the problem with cross-compilation in general and not just the special case of 32 and 64-bit x86. I prefer using architecture tag in the directory name rather than the file name because it makes setting up users' projects easier and doesn't require changes to auto-linking. This is also the approach taken in operating systems, including Windows and Linux.
On Mon, Mar 7, 2016 at 11:18 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
2. People responding with "+N".. Which of the following would you prefer? And give rationale for your preference, and optionally give rationales for not preferring others:
A) Having file names with "32" *and* "64" on them?
I prefer option A. It's consistent, doesn't require separate directories. The architecture is key of the build variant just like the type of CRT used, and whether it is a static or dynamic library, and I don't have any good reasons for why it should be special cased. Glen
Glen Fernandes wrote:
On Mon, Mar 7, 2016 at 11:18 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
2. People responding with "+N".. Which of the following would you prefer? And give rationale for your preference, and optionally give rationales for not preferring others:
A) Having file names with "32" *and* "64" on them?
I prefer option A. It's consistent, doesn't require separate directories. The architecture is key of the build variant just like the type of CRT used, and whether it is a static or dynamic library, and I don't have any good reasons for why it should be special cased.
I also prefer option A, for the same reasons. Any argument against encoding the architecture into the name also applies to the other things that we already encode.
Am 08.03.2016 um 05:18 schrieb Rene Rivera:
D) Having the current names and placing 32 bit address-model variants in "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)
I prefer option D because this is how I deploy Boost in our company since 2009. Until today I rename 'lib' to 'lib$(PlatformArchitecture)' by hand before deployment. Ciao Dani
On 8/03/2016 17:18, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
I think the only people who don't fancy auto-linking are probably those who are building on Linux or multi-platform, and so can't make use of it. Encourage the gcc/clang devs to add support for it. :)
A) Having file names with "32" *and* "64" on them?
Yes, but rather than just 32 and 64 it should be the actual arch name. Libraries built for ARM should be readily distinguishable from those for x86.
D) Having the current names and placing 32 bit address-model variants in "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)
This would be good as well (though again using the arch name, not just bit level). In fact the option I would personally prefer would be to do both of these at once -- embed the arch into the library name, but also build it to an arch-named output directory. It's not unreasonable to have different library paths for different arches, and with auto-linking the difference in library names is not important when building -- but having different names is important when distributing them local with an application; imagine a case where both a 32-bit exe and a 64-bit exe are to be installed to the same folder. Currently this is not possible because the Boost DLLs will clash. Even where auto-linking is not used, it's just a matter of specifying the library name in the project file / makefile / whatever with a placeholder variable for the arch, or conditionally setting the list of libraries in the same fashion as the library search path. It's not that hard.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: 08 March 2016 22:45 To: boost@lists.boost.org Subject: Re: [boost] 32/64 library name conflict under Windows?
On 8/03/2016 17:18, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
I think the only people who don't fancy auto-linking are probably those who are building on Linux or multi-platform, and so can't make use of it. Encourage the gcc/clang devs to add support for it. :)
A) Having file names with "32" *and* "64" on them?
Yes, but rather than just 32 and 64 it should be the actual arch name. Libraries built for ARM should be readily distinguishable from those for x86.
+1 for x86, x64, arm ...
In fact the option I would personally prefer would be to do both of these at once -- embed the arch into the library name, but also build it to an arch-named output directory.
It's not unreasonable to have different library paths for different arches, and with auto-linking the difference in library names is not important when building -- but having different names is important when distributing them local with an application; imagine a case where both a 32-bit exe and a 64-bit exe are to be installed to the same folder. Currently this is not possible because the Boost DLLs will clash.
Even where auto-linking is not used, it's just a matter of specifying the library name in the project file / makefile / whatever with a placeholder variable for the arch, or conditionally setting the list of libraries in the same fashion as the library search path. It's not that hard.
If some people want to split into arch-based folders /x86 /x64 /arm ..., then can't they easily do this at library build time http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta... "To use a different directory pass the --stagedir=directory option to b2." A few typical build command lines could be provided to help? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 9 March 2016 at 10:35, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: 08 March 2016 22:45 To: boost@lists.boost.org Subject: Re: [boost] 32/64 library name conflict under Windows?
On 8/03/2016 17:18, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
I think the only people who don't fancy auto-linking are probably those who are building on Linux or multi-platform, and so can't make use of it. Encourage the gcc/clang devs to add support for it. :)
A) Having file names with "32" *and* "64" on them?
Yes, but rather than just 32 and 64 it should be the actual arch name. Libraries built for ARM should be readily distinguishable from those for x86.
+1 for x86, x64, arm ...
In fact the option I would personally prefer would be to do both of these at once -- embed the arch into the library name, but also build it to an arch-named output directory.
It's not unreasonable to have different library paths for different arches, and with auto-linking the difference in library names is not important when building -- but having different names is important when distributing them local with an application; imagine a case where both a 32-bit exe and a 64-bit exe are to be installed to the same folder. Currently this is not possible because the Boost DLLs will clash.
Even where auto-linking is not used, it's just a matter of specifying the library name in the project file / makefile / whatever with a placeholder variable for the arch, or conditionally setting the list of libraries in the same fashion as the library search path. It's not that hard.
If some people want to split into arch-based folders /x86 /x64 /arm ..., then can't they easily do this at library build time
http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta...
"To use a different directory pass the --stagedir=directory option to b2."
A few typical build command lines could be provided to help?
If arch type is not somewhere by default (that is, boost distribution officially put these files somewhere clear and identifiable), it means that the tools can't rely on a specific path to find the right binaries.
Paul
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Klaim - Joël Lamotte Sent: 09 March 2016 10:53 To: Boost Developers List Subject: Re: [boost] 32/64 library name conflict under Windows?
On 9 March 2016 at 10:35, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: 08 March 2016 22:45 To: boost@lists.boost.org Subject: Re: [boost] 32/64 library name conflict under Windows?
On 8/03/2016 17:18, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
I think the only people who don't fancy auto-linking are probably those who are building on Linux or multi-platform, and so can't make use of it. Encourage the gcc/clang devs to add support for it. :)
A) Having file names with "32" *and* "64" on them?
Yes, but rather than just 32 and 64 it should be the actual arch name. Libraries built for ARM should be readily distinguishable from those for x86.
+1 for x86, x64, arm ...
In fact the option I would personally prefer would be to do both of these at once -- embed the arch into the library name, but also build it to an arch-named output directory.
It's not unreasonable to have different library paths for different arches, and with auto-linking the difference in library names is not important when building -- but having different names is important when distributing them local with an application; imagine a case where both a 32-bit exe and a 64-bit exe are to be installed to the same folder. Currently this is not possible because the Boost DLLs will clash.
Even where auto-linking is not used, it's just a matter of specifying the library name in the project file / makefile / whatever with a placeholder variable for the arch, or conditionally setting the list of libraries in the same fashion as the library search path. It's not that hard.
If some people want to split into arch-based folders /x86 /x64 /arm ..., then can't they easily do this at library build time
http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta...
"To use a different directory pass the --stagedir=directory option to b2."
A few typical build command lines could be provided to help?
If arch type is not somewhere by default (that is, boost distribution officially put these files somewhere clear and identifiable), it means that the tools can't rely on a specific path to find the right binaries.
Agreed - and the default should be to put everything in one folder, as now. But those building their own libraries, can easy do differently what they want (and take the consequences of other changes needed in consequence)? Paul
On March 9, 2016 5:53:08 AM EST, "Klaim - Joël Lamotte" <mjklaim@gmail.com> wrote:
On 9 March 2016 at 10:35, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
If some people want to split into arch-based folders /x86 /x64 /arm ..., then can't they easily do this at library build time
http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta...
"To use a different directory pass the --stagedir=directory option to b2."
A few typical build command lines could be provided to help?
If arch type is not somewhere by default (that is, boost distribution officially put these files somewhere clear and identifiable), it means that the tools can't rely on a specific path to find the right binaries.
What tools rely on Boost to put libraries in some official location? ___ Rob (Sent from my portable computation engine)
On 9 March 2016 at 20:49, Rob Stewart <rstewart@ptd.net> wrote:
On March 9, 2016 5:53:08 AM EST, "Klaim - Joël Lamotte" <mjklaim@gmail.com> wrote:
On 9 March 2016 at 10:35, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
If some people want to split into arch-based folders /x86 /x64 /arm ..., then can't they easily do this at library build time
http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta...
"To use a different directory pass the --stagedir=directory option to b2."
A few typical build command lines could be provided to help?
If arch type is not somewhere by default (that is, boost distribution officially put these files somewhere clear and identifiable), it means that the tools can't rely on a specific path to find the right binaries.
What tools rely on Boost to put libraries in some official location?
CMake's FindBoost.cmake module which is distributed with CMake for example. Several times in the past I built a boost version with default location (or got the binary distribution) and setup my project using CMake to use Boost. Then I get link time errors because I was compiling in 32bit (I use both 32 and 64bits in most of my projects) and Boost only existed in the native platform's architecture version. To help me remember about this issue, I setup a specific CMake macro in all my projects (which could be by someone else than me) to force the user at cmake's configure time to specify which binaries to use (I use separaet folders at the moment to provide the lib directory path to FindBoost.cmake).
___ Rob
(Sent from my portable computation engine)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2016-03-09 23:06, Klaim - Joël Lamotte wrote:
On 9 March 2016 at 20:49, Rob Stewart <rstewart@ptd.net> wrote:
On March 9, 2016 5:53:08 AM EST, "Klaim - Joël Lamotte" <mjklaim@gmail.com> wrote:
On 9 March 2016 at 10:35, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
If some people want to split into arch-based folders /x86 /x64 /arm ..., then can't they easily do this at library build time
http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta...
"To use a different directory pass the --stagedir=directory option to b2."
A few typical build command lines could be provided to help?
If arch type is not somewhere by default (that is, boost distribution officially put these files somewhere clear and identifiable), it means that the tools can't rely on a specific path to find the right binaries.
What tools rely on Boost to put libraries in some official location?
CMake's FindBoost.cmake module which is distributed with CMake for example.
Several times in the past I built a boost version with default location (or got the binary distribution) and setup my project using CMake to use Boost. Then I get link time errors because I was compiling in 32bit (I use both 32 and 64bits in most of my projects) and Boost only existed in the native platform's architecture version. To help me remember about this issue, I setup a specific CMake macro in all my projects (which could be by someone else than me) to force the user at cmake's configure time to specify which binaries to use (I use separaet folders at the moment to provide the lib directory path to FindBoost.cmake).
Well, whatever we choose to change (the default target directory or file names), CMake will need to be updated. Users' scripts too, unless they explicitly specify the target directory. Changing the target directory would be safer even.
On 9 March 2016 at 22:22, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 2016-03-09 23:06, Klaim - Joël Lamotte wrote:
On 9 March 2016 at 20:49, Rob Stewart <rstewart@ptd.net> wrote:
On March 9, 2016 5:53:08 AM EST, "Klaim - Joël Lamotte" <
mjklaim@gmail.com> wrote:
On 9 March 2016 at 10:35, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
If some people want to split into arch-based folders /x86 /x64 /arm
...,
then can't they easily do this at library build time
http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta...
"To use a different directory pass the --stagedir=directory option to b2."
A few typical build command lines could be provided to help?
If arch type is not somewhere by default (that is, boost distribution officially put these files somewhere clear and identifiable), it means that the tools can't rely on a specific path to find the right binaries.
What tools rely on Boost to put libraries in some official location?
CMake's FindBoost.cmake module which is distributed with CMake for example.
Several times in the past I built a boost version with default location (or got the binary distribution) and setup my project using CMake to use Boost. Then I get link time errors because I was compiling in 32bit (I use both 32 and 64bits in most of my projects) and Boost only existed in the native platform's architecture version. To help me remember about this issue, I setup a specific CMake macro in all my projects (which could be by someone else than me) to force the user at cmake's configure time to specify which binaries to use (I use separaet folders at the moment to provide the lib directory path to FindBoost.cmake).
Well, whatever we choose to change (the default target directory or file names), CMake will need to be updated. Users' scripts too, unless they explicitly specify the target directory. Changing the target directory would be safer even.
Upgrading CMake's FindBoost.cmake module is not hard, I was volunteer before to do the patch as soon as there is an official location rule. I'm less available these days but I could find the time to do so.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Paul A. Bristow wrote:
+1 for x86, x64, arm ...
+1. Another thing that would be pretty nice for Windows/autolink users would be something like b2 --target libboost_date_time-vc80-mt-sgd-1_61.lib to work, as the link error message one gets when the compiler/IDE can't find an autolinked library gives its name but it's not trivial to get from there to the required b2 command line.
AMDG On 03/09/2016 04:59 AM, Peter Dimov wrote:
Paul A. Bristow wrote:
+1 for x86, x64, arm ...
+1.
Another thing that would be pretty nice for Windows/autolink users would be something like
b2 --target libboost_date_time-vc80-mt-sgd-1_61.lib
to work, as the link error message one gets when the compiler/IDE can't find an autolinked library gives its name but it's not trivial to get from there to the required b2 command line.
What does work now is: b2 --build-type=complete msvc-8.0 libboost_date_time-vc80-mt-sgd-1_61.lib This effectively says generate all the targets as if you were building every possible combination, and then actually build only files named libboost_xxx. boost-git>b2 --build-type=complete libboost_system-vc140-mt-sgd-1_61.lib -n -d1 <snip> ...found 1300 targets... ...updating 5 targets... common.mkdir bin.v2\libs\system\build\msvc-14.0\debug\link-static\runtime-link-static common.mkdir bin.v2\libs\system\build\msvc-14.0\debug\link-static\runtime-link-static\threading-multi compile-c-c++ bin.v2\libs\system\build\msvc-14.0\debug\link-static\runtime-link-static\threading-multi\error_code.obj msvc.archive bin.v2\libs\system\build\msvc-14.0\debug\link-static\runtime-link-static\threading-multi\libboost_system-vc140-mt-sgd-1_61.lib common.copy stage\lib\libboost_system-vc140-mt-sgd-1_61.lib ...updated 5 targets... In Christ, Steven Watanabe
Steven Watanabe wrote:
On 03/09/2016 04:59 AM, Peter Dimov wrote:
Another thing that would be pretty nice for Windows/autolink users would be something like
b2 --target libboost_date_time-vc80-mt-sgd-1_61.lib
to work, as the link error message one gets when the compiler/IDE can't find an autolinked library gives its name but it's not trivial to get from there to the required b2 command line.
What does work now is:
b2 --build-type=complete msvc-8.0 libboost_date_time-vc80-mt-sgd-1_61.lib
Thanks, I did wonder whether something like that would work, but didn't try it. This should be documented in our "getting started" Windows guide.
On 2016-03-09 12:35, Paul A. Bristow wrote:
If some people want to split into arch-based folders /x86 /x64 /arm ..., then can't they easily do this at library build time
http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#insta...
"To use a different directory pass the --stagedir=directory option to b2."
A few typical build command lines could be provided to help?
The same kind of argument works for address-model as well. The point for adding the support for different target architectures to Boost.Build is to be able to build everything in one command. My preference is still to tag the directory. Aside from the mentioned benefit of easier user's project management, this also makes the stage directory more manageable. E.g. it's easier to delete or move or package binaries that correspond to a given architecture; no need for applying masks on file names.
On 09-Mar-16 12:35 PM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: 08 March 2016 22:45 To: boost@lists.boost.org Subject: Re: [boost] 32/64 library name conflict under Windows?
On 8/03/2016 17:18, Rene Rivera wrote:
1. Some people don't fancy auto-linking.
I think the only people who don't fancy auto-linking are probably those who are building on Linux or multi-platform, and so can't make use of it. Encourage the gcc/clang devs to add support for it. :)
A) Having file names with "32" *and* "64" on them?
Yes, but rather than just 32 and 64 it should be the actual arch name. Libraries built for ARM should be readily distinguishable from those for x86.
+1 for x86, x64, arm ...
The above is actually ambiguous - there's classic 32-bit arm and the 64-bit arm (aarch64). I also thing address size is orthogonal to architecture selection. If I have ARMv8 device, where ARMv8 is actually architecture name, I can still build 32-bit or 64-bit code. The same applies to MIPS. Possibly most people will prefer to run 64-bit OS and userspace on a chip that can do 64-bit, but 32-bit code is still a valid use case. -- Vladimir Prus http://vladimirprus.com
On 08 Mar 2016, at 05:18, Rene Rivera <grafikrobot@gmail.com> wrote:
2. People responding with "+N".. Which of the following would you prefer? And give rationale for your preference, and optionally give rationales for not preferring others:
My vote also goes to A for pretty much the same reasons already stated by others. Though, I also would prefer actual arch postfixes (-x86, -x64, -arm) instead of -32 and -64. Thomas
participants (14)
-
Andrey Semashev -
Boris Rasin -
Daniela Engert -
Gavin Lambert -
Glen Fernandes -
Ian Emmons -
Klaim - Joël Lamotte -
Paul A. Bristow -
Peter Dimov -
Rene Rivera -
Rob Stewart -
Steven Watanabe -
Thomas Trummer -
Vladimir Prus