Re: [Boost-users] [CMake] [boost][b2] Differenciate 32bit and 64 bit binaries when using CMake.
Júlio Hoffimann said:
I don't know if i understood correctly, but you can set the library directory by hand, please refer to /usr/share/cmake-<version>/Modules/FindBoost.cmake, in particular the variable BOOST_LIBRARYDIR.
On Thu, Oct 11, 2012 at 1:29 PM, Miller, Frank
A simple solution would be to install only the 64bit version of boost into a new directory and change the environment variable to point there. Then FindBoost will only be able to see the version you want.
Thanks, this will solve my immediate problem, but it don't solve it in general. (I will use it though, so thanks) I can't guarantee where the boost libraries are installed, that's why I use FindBoost. My current understanding is that boost don't have a specific default lib dir for different address models, which is the source of the problem as FindBoost script can't rely on a protocol to find these lib files. Am I correct? Joel Lamotte
On Thu, Oct 11, 2012 at 2:19 PM, Klaim - Joël Lamotte
My current understanding is that boost don't have a specific default lib dir for different address models, which is the source of the problem as FindBoost script can't rely on a protocol to find these lib files.
Am I correct?
I am getting back to this because it is becoming more a problem each day for me: I have several projects that would benefit from a 64bit version, but still need to be provided as a 32bit version too. Apparently setting BOOST_LIBRARYDIR does indeed allow to manually specify the library directory. I reported the issue ( http://www.cmake.org/Bug/view.php?id=14087 )that this is not documented in the help command or maybe it's because BOOST_LIBRARY_DIRS should be used instead but it don't work because BOOST_LIBRARY_DIRS is automatically overriden. In my specific case, as I need to build either the 32 bit or the 64bit version of the applications, I need to specify BOOST_LIBRARYDIR in both cases to be sure the user (other developers starting helping on the project) is linking with the correct version instead of relying on BOOST_DIR. This is not perfect but at least the developer can't ignore the issue. I am looking for suggestions to improve the situation, either on CMake or boost, as I'm not sure what to do exactly. I'm willing to subit patches to both to ease development of 32+64bits application using CMake and boost, so some directions on how to this issue would be useful. For now I think the simplest solution would be to make b2 use a default 64bit lib directory when the directory is unspecify. Then FindBoost cmake module can rely on this knowledge to try to find the right binaries, based on BOOST_Dir, instead of always using the same binaries by default. Does it seem like a good solution to you? Joel Lamotte
On Mon, 15 Apr 2013 16:59:25 +0200, Klaim - Joël Lamotte
For now I think the simplest solution would be to make b2 use a default 64bit lib directory when the directory is unspecify. Then FindBoost cmake module can rely on this knowledge to try to find the right binaries, based on BOOST_Dir, instead of always using the same binaries by default.
Does it seem like a good solution to you?
In my experience finding/adapting packages for crosscompiling 64->32 is much more troublesome than setting up 32-bit chroot and using it for 32-bit builds. -- Slava
On Tue, Apr 16, 2013 at 9:15 AM, Slava
In my experience finding/adapting packages for crosscompiling 64->32 is much more troublesome than setting up 32-bit chroot and using it for 32-bit builds.
Sorry but I don't understand, certainly because I'm still a noob at linux stuffs. I don't understand what you mean by crosscompiling here, do you mean cross compiling boost? The problem being how CMake will find the right binaries, I don't see how it solve the problem? Joel Lamotte
On Tue, 16 Apr 2013 11:50:17 +0200, Klaim - Joël Lamotte
Sorry but I don't understand, certainly because I'm still a noob at linux stuffs. I don't understand what you mean by crosscompiling here, do you mean cross compiling boost? The problem being how CMake will find the right binaries, I don't see how it solve the problem?
Joel Lamotte
You build 64-bit stuff (including boost if you wish) in 64-bit environment, 32-bit stuff (including boost if you wish) in a separate 32-bit environment. The environment is native for build tools, so you need no crosscompiling (-m32), no special library lookups. Google for 'linux 32-bit chroot' for more information. -- Slava
On Tue, Apr 16, 2013 at 12:32 PM, Slava
You build 64-bit stuff (including boost if you wish) in 64-bit environment, 32-bit stuff (including boost if you wish) in a separate 32-bit environment. The environment is native for build tools, so you need no crosscompiling (-m32), no special library lookups. Google for 'linux 32-bit chroot' for more information.
But then you need two compilation environment which not everyone can get (or be authorized to use in some companies). My point is that there shouldn't be a need for this: you can already compile for 64 or 32 bit with your compiler, only boost lacks a way to find the right binaries. I myself can't use another environment at the moment. And I don't want to, I need to work with a single laptop from everywhere and don't have space and patience for dual boot. Joel Lamotte.
"or be authorized to use in some companies"
How can that be so ?
If they want you to compile stuff how can they not allow you the resources to do so ?
"dual boot"
You could use Virtual Machines - that's what I do for odd platforms.
Unhelpfully,
Richard.
________________________________
From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Klaim - Joël Lamotte
Sent: 16 April 2013 11:41
To: Boost users list
Cc: cmake@cmake.org
Subject: Re: [Boost-users] [boost][b2] Differenciate 32bit and 64 bit binaries when using CMake.
On Tue, Apr 16, 2013 at 12:32 PM, Slava
On Tue, Apr 16, 2013 at 12:48 PM, Kerry, Richard
"or be authorized to use in some companies"
How can that be so ? If they want you to compile stuff how can they not allow you the resources to do so ?
Some companies will forbid usage of separate OS from the one they provide you if you will.
"dual boot" You could use Virtual Machines - that's what I do for odd platforms.
Yes, but it's still a heavy solution compared to just have a way for the CMake FindBoost module to find the right binaries. Using a virtual machine running Win 7 64bit into a Wind 7 64bit just because CMake have no way to find the right binaries because boost don't have a convention on identifying binaries is a bit ridiculous to me. There must be a way to have a simple solution which works for everybody. Why are everybody wanting me to use complicated setup when a simple convention on where to find by default what would solve this problem? Joel Lamotte.
On Tue, 16 Apr 2013 12:40:43 +0200, Klaim - Joël Lamotte
But then you need two compilation environment which not everyone can get (or be authorized to use in some companies).
By installing 32-bit packages into 64-bit environment you already get the second environment. chroot is merely a way to organize it more easily.
My point is that there shouldn't be a need for this: you can already compile for 64 or 32 bit with your compiler, only boost lacks a way to find the right binaries.
Not only, you'll find that out sooner or later :) For me that were ImageMagick and opengl. -- Slava
participants (3)
-
Kerry, Richard -
Klaim - Joël Lamotte -
Slava