From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-10-15 16:08:56
[2002-10-15] Vaclav Slavik wrote:
>I'm experiencing a nasty problem with Boost.build and Mingw32 on my
Which version of Boost.Build? The one with 1.29.0?
Which version of Boost.Jam? "bjam -v"
>Even a small project reaches command line length limit
>when building a DLL (because the rule for DLLs is not piecemeal one,
>unlike the one for static libs):
>mingw-Link-action actions too long (max 1023):
>-g -shared -mthreads -o
>As you can see, I am trying to build very small library, the linker is
>not passed million object files as its input. I think there are two
>1) Windows command line limitation, which nobody here can do anything
>about (or maybe it only applies to commands executed via command.com
>and if bjam executed g++ itself (i.e. by execing "g++ ..." and not
>'command.com g++ ..."), it wouldn't apply?
It applies to both. execvp type has a different limit than command.com,
which depend on which version of Windows you use. There's code in both
Boost.Build and Boost.Jam to deal with such things already.
>2) Boost.build generates excessively long filenames (viz
>and cmd line is therefore exhausted way too quickly.
>Is there some workaround/fix for this problem? I could globally
>replace e.g. "runtime-link" by "rtlnk" in Boost.build files, but it
>would a) only help (maybe!) me with my project, it would not help
>anything larger), and b) it would be at the cost of Jamfiles
The only way to reduce the depth of the variant directories is to create a
very specific variant for the builds you are doing. That is declare a
"variant" for you case that has the <threading>multi and
<runtime-link>dynamic set. That should remove those two subdirectories from
the build path. Example:
variant my-debug : debug : <threading>multi <runtime-link>dynamic ;
Then a "bjam -sBUILD=my-debug" will produce the shorter paths.
-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]
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