Re: [jamboost] mingw toolset and command-line length limitation problem

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-10-15 16:08:56

[2002-10-15] Vaclav Slavik wrote:

>Hello,
>
>I'm experiencing a nasty problem with Boost.build and Mingw32 on my 
>Windows98 box. 

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++ 
>-Wl,--exclude-symbols,_bss_end__:_bss_start__:_data_end__:_data_start__ 
>-Wl,--out-implib,objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\upf.lib 
>-g -shared -mthreads -o 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\upf.dll" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\classinfo.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\contexts.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\direnum.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\dll_loader.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\manager.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\marchaller.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\typeinfo.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\upfmain.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\condition.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\thread.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\mutex.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\xtime.obj" 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\exceptions.obj" 
>-Wl,-rpath-link,.
>"""
>
>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 
>problems here:
>
>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 
>"objs.tmp\upf.dll\mingw\debug\runtime-link-dynamic\threading-multi\exceptions.obj") 
>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 
>readibility...

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]