What's going on? For some reason I can no longer build boost. I'm trying to build version 1.39 using bjam. The same command worked just fine on 1.38: D:\IT\personal\asl_editor\temp\boost_1_39_0>bjam --toolset=msvc --layout=system link=static threading=multi debug release stage
Robert Dailey wrote:
What's going on? For some reason I can no longer build boost. I'm trying to build version 1.39 using bjam. The same command worked just fine on 1.38: D:\IT\personal\asl_editor\temp\boost_1_39_0>bjam --toolset=msvc --layout=system link=static threading=multi debug release stage
In general, if you don't believe in telepathy and the like, it's best to explain: 1. What you did exactly. 2. What exact results you got 3. How results are different from your expectation. Omitting (2), in particular, is not good idea. In this case, some telepathy might work -- you are using --layout=system. This produces names using system conventions -- more specifically, Unix system conventions -- and does not include any 'tags' for release/debug. I recommend dropping --layout=system (and you will be able to use autolink, even). - Volodya
Sorry for leaving the results out, I don't know what I was thinking. I was in too much of a hurry I suppose. Note that I really don't want to drop the layout=system, since if I do my LIB names get complex. I do not want the boost version number or anything else in the name. Basically, I want the names to look something like: boost_signals-mt-gd.lib boost_signals-mt.lib Now onto the results: warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:1056: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage\lib>libboost_date_time.lib error: previous virtual target { common%common.copy-libboost_date_time.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time.lib.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generators.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_date_time.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time.lib.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generators.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:480: in actualize-no-scanner from module object(file-target)@3270 D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:130: in object(file-target)@3270.actualize from module object(file-target)@3270 D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2\build-system.jam:713: in load from module build-system D:\IT\personal\asl_editor\temp\boost_1_39_0\tools\build\v2/kernel\modules.jam:283: in import from module modules D:\IT\personal\asl_editor\temp\boost_1_39_0\tools\build\v2/kernel/bootstrap.jam:138: in boost-build from module D:\IT\personal\asl_editor\temp\boost_1_39_0\boost-build.jam:16: in module scope from module On Thu, May 14, 2009 at 12:22 AM, Vladimir Prus <vladimir@codesourcery.com>wrote:
Robert Dailey wrote:
What's going on? For some reason I can no longer build boost. I'm trying to build version 1.39 using bjam. The same command worked just fine on 1.38: D:\IT\personal\asl_editor\temp\boost_1_39_0>bjam --toolset=msvc --layout=system link=static threading=multi debug release stage
In general, if you don't believe in telepathy and the like, it's best to explain:
1. What you did exactly. 2. What exact results you got 3. How results are different from your expectation.
Omitting (2), in particular, is not good idea.
In this case, some telepathy might work -- you are using --layout=system. This produces names using system conventions -- more specifically, Unix system conventions -- and does not include any 'tags' for release/debug. I recommend dropping --layout=system (and you will be able to use autolink, even).
- Volodya
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thu, May 14, 2009 at 8:15 AM, Robert Dailey <rcdailey@gmail.com> wrote:
Sorry for leaving the results out, I don't know what I was thinking. I was in too much of a hurry I suppose. Note that I really don't want to drop the layout=system, since if I do my LIB names get complex. I do not want the boost version number or anything else in the name. Basically, I want the names to look something like: boost_signals-mt-gd.lib boost_signals-mt.lib
Now onto the results:
warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:1056: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage\lib>libboost_date_time.lib error: previous virtual target { common%common.copy-libboost_date_time.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time.lib.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generators.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_date_time.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time.lib.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generators.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:480: in actualize-no-scanner from module object(file-target)@3270 D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:130: in object(file-target)@3270.actualize from module object(file-target)@3270 D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2\build-system.jam:713: in load from module build-system D:\IT\personal\asl_editor\temp\boost_1_39_0\tools\build\v2/kernel\modules.jam:283: in import from module modules D:\IT\personal\asl_editor\temp\boost_1_39_0\tools\build\v2/kernel/bootstrap.jam:138: in boost-build from module D:\IT\personal\asl_editor\temp\boost_1_39_0\boost-build.jam:16: in module scope from module
Sorry to rush this, but I'm completely blocked until I can build boost with reasonable library names on Windows. Can anyone help me figure out what I need to do to get the library names generated without any mangling? Thanks in advance.
On Thu, May 14, 2009 at 01:38:35PM -0500, Robert Dailey wrote:
Sorry to rush this, but I'm completely blocked until I can build boost with reasonable library names on Windows. Can anyone help me figure out what I need to do to get the library names generated without any mangling?
Sorry for jumping into the discussion, but I'm curious.. You probably do not build boost every day, so why don't you just manually rename or copy the resulting lib files to some sane names?
On Thu, May 14, 2009 at 1:45 PM, Zeljko Vrba <zvrba@ifi.uio.no> wrote:
On Thu, May 14, 2009 at 01:38:35PM -0500, Robert Dailey wrote:
Sorry to rush this, but I'm completely blocked until I can build boost
with
reasonable library names on Windows. Can anyone help me figure out what I need to do to get the library names generated without any mangling?
Sorry for jumping into the discussion, but I'm curious.. You probably do not build boost every day, so why don't you just manually rename or copy the resulting lib files to some sane names?
Because if I decide to use shared libraries, doing so will prevent the import libraries from finding their corresponding shared library. Not to mention that this is tedious to do. I would have to do this each time I upgrade boost. @Valdimir I apologize, I must not be communicating with you in the same language. I thought this would be simple to explain. Let me try to explain this with as many details as I can just to make sure I'm clear. When I built boost 1.38 for Windows x86 using VS9, I used the following command line: bjam --toolset=msvc --layout=system link=shared threading=multi release debug stage * * When I did this, my library names looked like this (For the Boost.Filesystem library): boost_filesystem-mt-gd.lib boost_filesystem-mt.lib Everything worked just fine. The reason why I used --layout=system was so that the library names were more simplified and did not contain information like the version of boost used. However, when I try the very same command line with Boost 1.39 I get the errors I posted earlier. I can't explain this any simpler than I am. I am merely a user of boost, I do not have the domain knowledge to delve into Boost.Build, nor do I want to learn it. My goal is to build boost the way I want, not to learn a new build system. I'm already a bit upset that this is turning out to be so complicated, I just want it to work like it is supposed to. There is no documentation I have been able to find that discusses why this worked in 1.38 but breaks in 1.39 on Windows. My searching on Google has come up with very few results, and of those results the issue still isn't made very clear. No one has been able to explain to me, clearly, what exactly to do to get this to work. I'm not asking for much. What I'm asking should be one of the simplest questions to answer on this list. If I am still not being clear or if I am failing to provide certain information, please let me know.
Robert Dailey wrote:
On Thu, May 14, 2009 at 1:45 PM, Zeljko Vrba <zvrba@ifi.uio.no> wrote:
On Thu, May 14, 2009 at 01:38:35PM -0500, Robert Dailey wrote:
Sorry to rush this, but I'm completely blocked until I can build boost
with
reasonable library names on Windows. Can anyone help me figure out what I need to do to get the library names generated without any mangling?
Sorry for jumping into the discussion, but I'm curious.. You probably do not build boost every day, so why don't you just manually rename or copy the resulting lib files to some sane names?
Because if I decide to use shared libraries, doing so will prevent the import libraries from finding their corresponding shared library. Not to mention that this is tedious to do. I would have to do this each time I upgrade boost.
@Valdimir
I apologize, I must not be communicating with you in the same language. I thought this would be simple to explain. Let me try to explain this with as many details as I can just to make sure I'm clear. When I built boost 1.38 for Windows x86 using VS9, I used the following command line:
bjam --toolset=msvc --layout=system link=shared threading=multi release debug stage * * When I did this, my library names looked like this (For the Boost.Filesystem library):
boost_filesystem-mt-gd.lib boost_filesystem-mt.lib
Everything worked just fine. The reason why I used --layout=system was so that the library names were more simplified and did not contain information like the version of boost used.
However, when I try the very same command line with Boost 1.39 I get the errors I posted earlier. I can't explain this any simpler than I am. I am merely a user of boost, I do not have the domain knowledge to delve into Boost.Build, nor do I want to learn it. My goal is to build boost the way I want, not to learn a new build system. I'm already a bit upset that this is turning out to be so complicated, I just want it to work like it is supposed to.
Because we go any further: do you know what 'patch file' is and what to do with it? - Volodya
On Thu, May 14, 2009 at 2:24 PM, Vladimir Prus <vladimir@codesourcery.com>wrote:
Robert Dailey wrote:
On Thu, May 14, 2009 at 1:45 PM, Zeljko Vrba <zvrba@ifi.uio.no> wrote:
On Thu, May 14, 2009 at 01:38:35PM -0500, Robert Dailey wrote:
Sorry to rush this, but I'm completely blocked until I can build boost
with
reasonable library names on Windows. Can anyone help me figure out what I need to do to get the library names generated without any mangling?
Sorry for jumping into the discussion, but I'm curious.. You probably do not build boost every day, so why don't you just manually rename or copy the resulting lib files to some sane names?
Because if I decide to use shared libraries, doing so will prevent the import libraries from finding their corresponding shared library. Not to mention that this is tedious to do. I would have to do this each time I upgrade boost.
@Valdimir
I apologize, I must not be communicating with you in the same language. I thought this would be simple to explain. Let me try to explain this with as many details as I can just to make sure I'm clear. When I built boost 1.38 for Windows x86 using VS9, I used the following command line:
bjam --toolset=msvc --layout=system link=shared threading=multi release debug stage * * When I did this, my library names looked like this (For the Boost.Filesystem library):
boost_filesystem-mt-gd.lib boost_filesystem-mt.lib
Everything worked just fine. The reason why I used --layout=system was so that the library names were more simplified and did not contain information like the version of boost used.
However, when I try the very same command line with Boost 1.39 I get the errors I posted earlier. I can't explain this any simpler than I am. I am merely a user of boost, I do not have the domain knowledge to delve into Boost.Build, nor do I want to learn it. My goal is to build boost the way I want, not to learn a new build system. I'm already a bit upset that this is turning out to be so complicated, I just want it to work like it is supposed to.
Because we go any further: do you know what 'patch file' is and what to do with it?
Yes, I did not mean to imply that I was that clueless lol. I just don't know squat about Boost.Build, that's all. Are you implying that this is a bug in Boost.Build (or Boost itself) and that a patch has been made to fix it?
Robert Dailey wrote:
On Thu, May 14, 2009 at 2:24 PM, Vladimir Prus <vladimir@codesourcery.com>wrote:
Robert Dailey wrote:
On Thu, May 14, 2009 at 1:45 PM, Zeljko Vrba <zvrba@ifi.uio.no> wrote:
On Thu, May 14, 2009 at 01:38:35PM -0500, Robert Dailey wrote:
Sorry to rush this, but I'm completely blocked until I can build boost
with
reasonable library names on Windows. Can anyone help me figure out what I need to do to get the library names generated without any mangling?
Sorry for jumping into the discussion, but I'm curious.. You probably do not build boost every day, so why don't you just manually rename or copy the resulting lib files to some sane names?
Because if I decide to use shared libraries, doing so will prevent the import libraries from finding their corresponding shared library. Not to mention that this is tedious to do. I would have to do this each time I upgrade boost.
@Valdimir
I apologize, I must not be communicating with you in the same language. I thought this would be simple to explain. Let me try to explain this with as many details as I can just to make sure I'm clear. When I built boost 1.38 for Windows x86 using VS9, I used the following command line:
bjam --toolset=msvc --layout=system link=shared threading=multi release debug stage * * When I did this, my library names looked like this (For the Boost.Filesystem library):
boost_filesystem-mt-gd.lib boost_filesystem-mt.lib
Everything worked just fine. The reason why I used --layout=system was so that the library names were more simplified and did not contain information like the version of boost used.
However, when I try the very same command line with Boost 1.39 I get the errors I posted earlier. I can't explain this any simpler than I am. I am merely a user of boost, I do not have the domain knowledge to delve into Boost.Build, nor do I want to learn it. My goal is to build boost the way I want, not to learn a new build system. I'm already a bit upset that this is turning out to be so complicated, I just want it to work like it is supposed to.
Because we go any further: do you know what 'patch file' is and what to do with it?
Yes, I did not mean to imply that I was that clueless lol. I just don't know squat about Boost.Build, that's all.
No offense intended -- many people don't know, and there are alternatives. Can you please apply the attached, replace --layout=system with --layout=tagged and try again? You should get the same results that --layout=system had in 1.38.
Are you implying that this is a bug in Boost.Build (or Boost itself) and that a patch has been made to fix it?
It is not a bug -- system layout was changed on the purpose and will stay this way. It's just everybody has different requirements and desired naming. - Volodya
On Thu, May 14, 2009 at 3:57 PM, Vladimir Prus <vladimir@codesourcery.com>wrote:
No offense intended -- many people don't know, and there are alternatives. Can you please apply the attached, replace --layout=system with --layout=tagged and try again? You should get the same results that --layout=system had in 1.38.
I was not offended. I was actually joking about it, but it's hard to express that through text. It is not a bug -- system layout was changed on the purpose and will stay
this way. It's just everybody has different requirements and desired naming.
What exactly was it changed to? I have *never* found a library that used a naming convention that boost uses. I also have yet to find someone that actually likes the mangled boost library names. There is no practical reason to use mangled names as far as I'm concerned. The only thing that I can think of that the extra mangling would address is side-by-side installations of boost. For example, someone could have 1.38 and 1.39 installed together on the same system and library files will coexist, and not be overwritten. Anyway, thank you for the patch. I will try it out when I get home in a few hours.
Robert Dailey wrote:
On Thu, May 14, 2009 at 3:57 PM, Vladimir Prus <vladimir@codesourcery.com>wrote:
No offense intended -- many people don't know, and there are alternatives. Can you please apply the attached, replace --layout=system with --layout=tagged and try again? You should get the same results that --layout=system had in 1.38.
I was not offended. I was actually joking about it, but it's hard to express that through text.
It is not a bug -- system layout was changed on the purpose and will stay
this way. It's just everybody has different requirements and desired naming.
What exactly was it changed to?
It was changed to not adding anything to the name (not even "mt" or "d), except that on Unix, version number is added at the end -- after ".so" extension, and a symlink without version number is created.
I have *never* found a library that used a naming convention that boost uses. I also have yet to find someone that actually likes the mangled boost library names. There is no practical reason to use mangled names as far as I'm concerned.
On Unix, or on Windows? On Unix you are right, and --layout=system in 1.39 produces names that use the same convention as every other library. On Windows, I have no idea.
The only thing that I can think of that the extra mangling would address is side-by-side installations of boost. For example, someone could have 1.38 and 1.39 installed together on the same system and library files will coexist, and not be overwritten.
Anyway, thank you for the patch. I will try it out when I get home in a few hours.
Let me know if it works. - Volodya
On Thu, May 14, 2009 at 4:43 PM, Vladimir Prus <vladimir@codesourcery.com>wrote:
Robert Dailey wrote:
On Thu, May 14, 2009 at 3:57 PM, Vladimir Prus < vladimir@codesourcery.com>wrote:
No offense intended -- many people don't know, and there are
alternatives.
Can you please apply the attached, replace --layout=system with --layout=tagged and try again? You should get the same results that --layout=system had in 1.38.
I was not offended. I was actually joking about it, but it's hard to express that through text.
It is not a bug -- system layout was changed on the purpose and will stay
this way. It's just everybody has different requirements and desired naming.
What exactly was it changed to?
It was changed to not adding anything to the name (not even "mt" or "d), except that on Unix, version number is added at the end -- after ".so" extension, and a symlink without version number is created.
I have *never* found a library that used a naming convention that boost uses. I also have yet to find someone that actually likes the mangled boost library names. There is no practical reason to use mangled names as far as I'm concerned.
On Unix, or on Windows? On Unix you are right, and --layout=system in 1.39 produces names that use the same convention as every other library. On Windows, I have no idea.
The only thing that I can think of that the extra mangling would address is side-by-side installations of boost. For example, someone could have 1.38 and 1.39 installed together on the same system and library files will coexist, and not be overwritten.
Anyway, thank you for the patch. I will try it out when I get home in a few hours.
Let me know if it works.
I think I might be having trouble with the patch. I downloaded patch.exe for windows and I ran the following inside of the boost_1_39_0 directory: patch.exe tagged.diff Jamroot The output I get is: **** Only garbage was found in the patch input Am I doing something wrong? Or is the patch file corrupt?
AMDG Robert Dailey wrote:
I think I might be having trouble with the patch. I downloaded patch.exe for windows and I ran the following inside of the boost_1_39_0 directory:
patch.exe tagged.diff Jamroot
The output I get is:
**** Only garbage was found in the patch input
Am I doing something wrong? Or is the patch file corrupt?
Steven@D3RTHVC1 ~ $ man patch PATCH(1) PATCH(1) NAME patch - apply a diff file to an original SYNOPSIS patch [options] [originalfile [patchfile]] but usually just patch -pnum <patchfile In Christ, Steven Watanabe
On Thu, May 14, 2009 at 10:31 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
Steven@D3RTHVC1 ~ $ man patch
PATCH(1) PATCH(1)
NAME patch - apply a diff file to an original
SYNOPSIS patch [options] [originalfile [patchfile]]
but usually just
patch -pnum <patchfile
I already know the syntax. I don't understand what you're telling me. You say to use -p, but what number do I put after it? Please provide more exact details.
AMDG Robert Dailey wrote:
On Thu, May 14, 2009 at 10:31 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
Steven@D3RTHVC1 ~ $ man patch
PATCH(1) PATCH(1)
NAME patch - apply a diff file to an original
SYNOPSIS patch [options] [originalfile [patchfile]]
but usually just
patch -pnum <patchfile
I already know the syntax. I don't understand what you're telling me. You say to use -p, but what number do I put after it? Please provide more exact details.
You had the order of the arguments backwards. the patch file comes after the original file. In Christ, Steven Watanabe
On Thu, May 14, 2009 at 10:43 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
You had the order of the arguments backwards. the patch file comes after the original file.
Oh silly me. Thanks for that, I didn't realize I was making such an obvious mistake. Anyway, I managed to apply the patch just fine. The library names seem to be coming out as I expect. The build will take quite a while, so when it is finished I'll post back here if I see any issues. The only weirdness I see is with Boost.Math: libboost_math_c99-mt-gd.lib I don't think I remember seeing the c99 part in the name before. But I don't think I ever paid much attention to it. Everything else looks familiar, though. Thanks for the help everyone.
Robert Dailey wrote:
On Thu, May 14, 2009 at 10:43 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
You had the order of the arguments backwards. the patch file comes after the original file.
Oh silly me. Thanks for that, I didn't realize I was making such an obvious mistake.
Anyway, I managed to apply the patch just fine. The library names seem to be coming out as I expect. The build will take quite a while, so when it is finished I'll post back here if I see any issues.
The only weirdness I see is with Boost.Math:
libboost_math_c99-mt-gd.lib
I don't think I remember seeing the c99 part in the name before.
I am pretty sure it was there.
But I don't think I ever paid much attention to it. Everything else looks familiar, though. Thanks for the help everyone.
I've checked in the patch (with additional changes the "bjam --help" output) to trunk, and merged to release branch. - Volodya
On Fri, May 15, 2009 at 12:38 AM, Vladimir Prus <vladimir@codesourcery.com>wrote:
I've checked in the patch (with additional changes the "bjam --help" output) to trunk, and merged to release branch.
I have one more question Valdimir, if you don't mind. I noticed that the library names (for static libraries) are named like so (On Windows): libboost_filesystem-mt.lib The 'lib' prefix is a linux pattern that normally isn't used on Windows. This actually confuses the FindBoost.cmake module in CMake. Has it always been this way for static boost libraries? I know the boost import libraries (when building shared libraries) never had the 'lib' prefix.
AMDG Robert Dailey wrote:
On Fri, May 15, 2009 at 12:38 AM, Vladimir Prus <vladimir@codesourcery.com>wrote:
I've checked in the patch (with additional changes the "bjam --help" output) to trunk, and merged to release branch.
I have one more question Valdimir, if you don't mind.
I noticed that the library names (for static libraries) are named like so (On Windows):
libboost_filesystem-mt.lib
The 'lib' prefix is a linux pattern that normally isn't used on Windows. This actually confuses the FindBoost.cmake module in CMake. Has it always been this way for static boost libraries? I know the boost import libraries (when building shared libraries) never had the 'lib' prefix.
Yes it has always been this way. The naming convention is static library: libboost_xxx.lib import library: boost_xxx.lib dll: boost_xxx.dll This allows the import libraries to be distinguished from the static libraries. In Christ, Steven Watanabe
On Sat, May 16, 2009 at 11:38 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
Yes it has always been this way. The naming convention is static library: libboost_xxx.lib import library: boost_xxx.lib dll: boost_xxx.dll
This allows the import libraries to be distinguished from the static libraries.
That's what I thought, but I just wanted to make sure I wasn't forgetting. Looks like CMake's FindBoost.cmake module is broken, then. I'll let them know.
The only weirdness I see is with Boost.Math:
libboost_math_c99-mt-gd.lib
I don't think I remember seeing the c99 part in the name before. But I don't think I ever paid much attention to it. Everything else looks familiar, though. Thanks for the help everyone.
There wasn't a Boost.Math binary before, and it's always had that name :-) John.
Robert Dailey wrote:
On Thu, May 14, 2009 at 8:15 AM, Robert Dailey <rcdailey@gmail.com> wrote:
Sorry for leaving the results out, I don't know what I was thinking. I was in too much of a hurry I suppose. Note that I really don't want to drop the layout=system, since if I do my LIB names get complex. I do not want the boost version number or anything else in the name. Basically, I want the names to look something like: boost_signals-mt-gd.lib boost_signals-mt.lib
Now onto the results:
warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:1056: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage\lib>libboost_date_time.lib error: previous virtual target { common%common.copy-libboost_date_time.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time.lib.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generators.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: another virtual target { common%common.copy-libboost_date_time.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time.lib.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/greg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { gregorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generators.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./stage-proper error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:480: in actualize-no-scanner from module object(file-target)@3270 D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2/build\virtual-target.jam:130: in object(file-target)@3270.actualize from module object(file-target)@3270 D:/IT/personal/asl_editor/temp/boost_1_39_0/tools/build/v2\build-system.jam:713: in load from module build-system D:\IT\personal\asl_editor\temp\boost_1_39_0\tools\build\v2/kernel\modules.jam:283: in import from module modules D:\IT\personal\asl_editor\temp\boost_1_39_0\tools\build\v2/kernel/bootstrap.jam:138: in boost-build from module D:\IT\personal\asl_editor\temp\boost_1_39_0\boost-build.jam:16: in module scope from module
Sorry to rush this, but I'm completely blocked until I can build boost with reasonable library names on Windows. Can anyone help me figure out what I need to do to get the library names generated without any mangling?
Sorry -- "without"? That is what system layout does now, which you have objected in the first place. Can you maybe explain what properties, exactly, you want to see present? And you get your unblocked -- see Jamroot, the 'tag' rule. Compare versioned and system layouts and adjust the system layout to request necessary thing to appear in name -- it should be straightforward. - Volodya
Thanks in advance.
participants (5)
-
John Maddock -
Robert Dailey -
Steven Watanabe -
Vladimir Prus -
Zeljko Vrba