"David Abrahams" wrote in message news:u7kgfqx6f.fsf@boost-consulting.com...

"Fernando Cacciola" writes:

...

Hi,

I'm having a hard time trying to use bjam to build boost 1.29.0. I have Win98 in Spanish, and I use Borland C++ Builder 5.0 (its bcc32.exe corresponds to is BCC5.5.1)

I have boost 1.29.0 installed at: "C:\Libraries\boost\Repository\boost"

<snip>

...

If I'm interpreting this output correctly, the problem is that the command line feed to bcc32 exceeds 256 characters.

What can be done about this? Is there a way for 'borland-tools.jam' to put the bcc32 parameters in a tmp response file and use: bcc32.exe @tmprsp.rsp?

Any help will be appreciated.

Fernando,

Unfortunately, bjam is somewhat limited by the underlying shell used to actually run the build commands. We've had a hard time getting it to cooperate with Win9x for that reason. John Maddock has had some success by building and running bjam under Cygwin, which has no command-line length limitation. I'm not sure whether it can be made to run the Borland toolset that way or not, but I know that John targets Borland so it's a good bet.

OK, this might work... thank you. The only problem is that the cygwin-bjam that I've just downloaded from: http://www.boost.org/tools/build/index.html#Jam yields an Access Violation when executed from within my cygwin installation. My cygwin bash.exe it's version 2.04.0(1)-release. Do you know if I require an updated version of cygwin, or is there a problem with the bjam executable? TIA, -- Fernando Cacciola

"Fernando Cacciola" writes:

...

"David Abrahams" wrote in message news:u7kgfqx6f.fsf@boost-consulting.com...

...

"Fernando Cacciola" writes:

Do you know if I require an updated version of cygwin, or is there a

"David Abrahams" wrote in message news:uelanm6jn.fsf@boost-consulting.com... problem

...

with the bjam executable?

I don't know, but rebuilding bjam within cygwin is as easy as

make CC=gcc

from within the tools/build/jam_src directory.

Good. John said it won't work for Win32 executables, but it seems that it will work for cygwin-based apps; I might find a use for that. Thanks, -- Fernando Cacciola

If John could explain what the problem is (he mentioned absolute paths, but Boost.Build doesn't really use absolute paths so I'm still a bit confused), maybe a small tweak could be applied to fix it up.

I don't think that a small tweak will be enough: bjam -sTOOLS=borland -d2 regex ...found 526 targets... ...updating 83 targets... MkDir1 ../libs/regex/build/bin/libboost_regex.a/borland mkdir ../libs/regex/build/bin/libboost_regex.a/borland MkDir1 ../libs/regex/build/bin/libboost_regex.a/borland/debug mkdir ../libs/regex/build/bin/libboost_regex.a/borland/debug MkDir1 ../libs/regex/build/bin/libboost_regex.a/borland/debug/runtime-link-dynamic mkdir ../libs/regex/build/bin/libboost_regex.a/borland/debug/runtime-link-dynamic borland-C++-action ../libs/regex/build/bin/libboost_regex.a/borland/debug/runtime-link-dynamic/ c_regex_traits.o "bcc32" -j5 -q -c -P -w -Ve -Vx -a8 -DBOOST_REGEX_NO_LIB=1 -DBOOST_REGEX_S TATIC_LINK=1 -v -Od -vi- -tWC -tWR -WC -WM- -w-8001 -I"../libs/regex/buil d" -I"/cygdrive/d/boost/develop/boost" -o"../libs/regex/build/bin/libboost _regex.a/borland/debug/runtime-link-dynamic/c_regex_traits.o" "../libs/regex/build/../src/c_regex_traits.cpp" ../libs/regex/build/../src/c_regex_traits.cpp: Error E2209 ../libs/regex/build/../src/c_regex_traits.cpp 25: Unable to open inc lude file 'boost/config.hpp' ...interrupted ...updated 3 targets... There are two issues here: the boost include path is always an absolute /cygdrive/d/.. path whatever I do with BOOST_ROOT, and the SUFOBJ SUFLIB etc are all set wrong. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm

You shouldn't be touching BOOST_ROOT. Where does this /cygdrive/d/ business come from? When I build using a cygwin bjam there are no absolute paths.

I don't know where it comes from! BOOST_ROOT is unset when I invoke bjam, but internally bjam is setting it to an absolute path: /cygdrive/d/boost/develop/boost. I haven't been able to override this.

...

and the SUFOBJ SUFLIB etc are all set wrong.

That's easy enough to work around on the command-line with

-sSUFOBJ=.obj -sSUFLIB=.lib

Or you can do it in the environment.

Granted, but it's a pain to have to do this, and obviously newbees won't know anything about it... John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm

I have been unable to build threads on cygwin using gcc or gcc-nocygwin. One thing I am puzzled by is that the tar file I downloaded does not have make files in tools/build/jam_src as David says.

Greg Silverman

--- In Boost-Users@yahoogroups.com, "Fernando Cacciola" wrote:

...

"David Abrahams" wrote in message news:uelanm6jn.fsf@b...

...

"Fernando Cacciola" writes:

...

"David Abrahams" wrote in message news:u7kgfqx6f.fsf@b...

...

"Fernando Cacciola" writes:

Do you know if I require an updated version of cygwin, or is

BTW: Does *anyone* build all of boost under Cygwin with "gcc -mno-cygwin"? I have so much trouble with this that I think I must be the only one trying to do it. Greg Silverman --- In Boost-Users@yahoogroups.com, "silvermangbs" wrote: there a

...

problem

...

...

with the bjam executable?

I don't know, but rebuilding bjam within cygwin is as easy as

make CC=gcc

from within the tools/build/jam_src directory.

Good. John said it won't work for Win32 executables, but it seems that it will work for cygwin-based apps; I might find a use for that.

Thanks,

-- Fernando Cacciola

"silvermangbs" writes:

I have been unable to build threads on cygwin using gcc or gcc-nocygwin. One thing I am puzzled by is that the tar file I downloaded does not have make files in tools/build/jam_src as David says.

Things have changed since 18 Oct 2002, when I wrote that. The instructions for rebuilding bjam are at: http://www.boost.org/tools/build/jam_src/index.html#installing If you're going to invoke it from within cygwin, you want the "Unix type platform" instructions.

Greg Silverman

--- In Boost-Users@yahoogroups.com, "Fernando Cacciola" wrote:

...

...

"Fernando Cacciola" writes:

...

"David Abrahams" wrote in message news:u7kgfqx6f.fsf@b...

...

"Fernando Cacciola" writes:

Do you know if I require an updated version of cygwin, or is there a

"David Abrahams" wrote in message news:uelanm6jn.fsf@b... problem

...

...

with the bjam executable?

I don't know, but rebuilding bjam within cygwin is as easy as

make CC=gcc

from within the tools/build/jam_src directory.

Good. John said it won't work for Win32 executables, but it seems that it will work for cygwin-based apps; I might find a use for that.

Thanks,

-- Fernando Cacciola

Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-- Dave Abrahams Boost Consulting www.boost-consulting.com

"silvermangbs" writes:

I looked at the website. The only mention of building bjam for gcc-nocygwin is with using build.bat.

You don't need to rebuild bjam for each toolset you want to use it with; you only need a new version for each *platform* you want to use it with [Rene, people keep making this mistake; would you mind updating the documentation to make this clear? -- thanks!]. Any compiler that works on that platform will do. On windows, the Windows command-line and the Cygwin shell are essentially two separate platforms. Note that gcc-nocygwin doesn't appear in the list of supported toolsets for building bjam under Cygwin, only for building bjam under Windows.

So, I ran (from a cygwin command line)

build.bat gcc-nocygwin

and, it failed while trying to build fileunix.o, as follows:

### ### Using 'gcc-nocygwin' toolset. ###

C:\cygwin\home\GregSilverman\boost\boost_1_30_0\tools\build\jam_src>rd /S /Q bootstrap.gcc-nocygwin

C:\cygwin\home\GregSilverman\boost\boost_1_30_0\tools\build\jam_src>md bootstrap.gcc-nocygwin

C:\cygwin\home\GregSilverman\boost\boost_1_30_0\tools\build\jam_src>gcc -mno-cygwin -o bootstrap.gcc-nocygwin\jam0.exe command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c fileunix.c:88:17: ar.h: No such file or directory fileunix.c: In function `file_archscan': fileunix.c:205: storage size of `ar_hdr' isn't known fileunix.c:214: `SARMAG' undeclared (first use in this function) fileunix.c:214: (Each undeclared identifier is reported only once fileunix.c:214: for each function it appears in.) fileunix.c:215: `ARMAG' undeclared (first use in this function) fileunix.c:226: sizeof applied to an incomplete type fileunix.c:226: sizeof applied to an incomplete type fileunix.c:227: `ARFMAG' undeclared (first use in this function) fileunix.c:252: sizeof applied to an incomplete type fileunix.c:283: sizeof applied to an incomplete type

Is there some other way to build bjam for gcc-nocygwin?

You don't build bjam *for* a toolset; you build it for a platform *with* a toolset. If you want to build from Cygwin (with any supported toolset), you can just use the gcc toolset to build bjam. And don't use build.bat unless you want a Windows-hosted bjam. If you really want to build from Cygwin, use build.sh. -- Dave Abrahams Boost Consulting www.boost-consulting.com

OK. But, now, do I need to run libs/config/configure to configure for gcc-nocygwin? Would I need to set any environment variables or command options to do that?

Thanks

Greg Silverman

--- In Boost-Users@yahoogroups.com, David Abrahams wrote:

...

"silvermangbs" writes:

...

I looked at the website. The only mention of building bjam for gcc-nocygwin is with using build.bat.

You don't need to rebuild bjam for each toolset you want to use it with; you only need a new version for each *platform* you want to use it with [Rene, people keep making this mistake; would you mind updating the documentation to make this clear? -- thanks!]. Any compiler that works on that platform will do.

On windows, the Windows command-line and the Cygwin shell are essentially two separate platforms. Note that gcc-nocygwin doesn't appear in the list of supported toolsets for building bjam under Cygwin, only for building bjam under Windows.

...

So, I ran (from a cygwin command line)

build.bat gcc-nocygwin

and, it failed while trying to build fileunix.o, as follows:

### ### Using 'gcc-nocygwin' toolset. ###

C:\cygwin\home\GregSilverman\boost\boost_1_30_0\tools\build\jam_src>rd

...

/S /Q bootstrap.gcc-nocygwin

C:\cygwin\home\GregSilverman\boost\boost_1_30_0\tools\build\jam_src>md

...

bootstrap.gcc-nocygwin

C:\cygwin\home\GregSilverman\boost\boost_1_30_0\tools\build\jam_src>gcc

...

-mno-cygwin -o bootstrap.gcc-nocygwin\jam0.exe command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c

Maybe I answered my own question. I set CXXFLAGS to -mno-cygwin and ran configure. The user.hpp file it generated allowed me to build the threads for the first time. --- In Boost-Users@yahoogroups.com, "silvermangbs" wrote: pathvms.c

...

...

regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c fileunix.c:88:17: ar.h: No such file or directory fileunix.c: In function `file_archscan': fileunix.c:205: storage size of `ar_hdr' isn't known fileunix.c:214: `SARMAG' undeclared (first use in this function) fileunix.c:214: (Each undeclared identifier is reported only once fileunix.c:214: for each function it appears in.) fileunix.c:215: `ARMAG' undeclared (first use in this function) fileunix.c:226: sizeof applied to an incomplete type fileunix.c:226: sizeof applied to an incomplete type fileunix.c:227: `ARFMAG' undeclared (first use in this function) fileunix.c:252: sizeof applied to an incomplete type fileunix.c:283: sizeof applied to an incomplete type

Is there some other way to build bjam for gcc-nocygwin?

You don't build bjam *for* a toolset; you build it for a platform *with* a toolset. If you want to build from Cygwin (with any supported toolset), you can just use the gcc toolset to build bjam. And don't use build.bat unless you want a Windows-hosted bjam. If you really want to build from Cygwin, use build.sh.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

"silvermangbs" writes:

...

Maybe I answered my own question. I set CXXFLAGS to -mno-cygwin and ran configure. The user.hpp file it generated allowed me to build the threads for the first time.

Running configure should generally not be needed, especially for well-supported platforms like Windows. I certainly built the

If I do not run configure first, I get the following link errors when I try to build threads gcc-Link- action ../../../libs/thread/build/bin/libboost_thread.dll/gcc- nocygwin/debug/runtime-link-dynamic/threading- multi/libboost_thread.dll /usr//lib/libstdc++.a(vterminate.o) (.text$_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x71): undefined reference to `_impure_ptr' /usr//lib/libstdc++.a(vterminate.o) (.text$_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xb6): undefined reference to `_impure_ptr' /usr//lib/libstdc++.a(cxa_demangle.o) (.text$demangle_v3_with_details+0x87): undefined reference to `_impure_ptr' /usr//lib/libstdc++.a(cxa_demangle.o) (.text$demangle_v3_with_details+0xaf): undefined reference to `_impure_ptr' /usr//lib/libstdc++.a(ios.o) (.text$_ZNSt8ios_base4Init13_S_ios_createEb+0x3e): undefined reference to `_impure_ptr' /usr//lib/libstdc++.a(ios.o) (.text$_ZNSt8ios_base4Init13_S_ios_createEb+0x67): more undefined references to `_impure_ptr' follow /usr//lib/libstdc++.a(locale.o) (.text$_ZNSt5ctypeIcE13classic_tableEv+0x4): undefined reference to `_imp___ctype_' /usr//lib/libstdc++.a(pure.o)(.text$__cxa_pure_virtual+0xe): undefined reference to `_impure_ptr' /usr//lib/libstdc++.a(c++locale.o) (.text$_ZSt14__convert_to_vIlEvPKcRT_RSt12_Ios_IostateRKPii+0x28): undefined reference to `__errno' /usr//lib/libstdc++.a(c++locale.o) (.text$_ZSt14__convert_to_vIlEvPKcRT_RSt12_Ios_IostateRKPii+0x5c): undefined reference to `__errno' /usr//lib/libstdc++.a(c++locale.o) (.text$_ZSt14__convert_to_vImEvPKcRT_RSt12_Ios_IostateRKPii+0x28): undefined reference to `__errno' /usr//lib/libstdc++.a(c++locale.o) (.text$_ZSt14__convert_to_vImEvPKcRT_RSt12_Ios_IostateRKPii+0x5c): undefined reference to `__errno' /usr//lib/libstdc++.a(c++locale.o) (.text$_ZSt14__convert_to_vIxEvPKcRT_RSt12_Ios_IostateRKPii+0x25): undefined reference to `__errno' /usr//lib/libstdc++.a(c++locale.o) (.text$_ZSt14__convert_to_vIxEvPKcRT_RSt12_Ios_IostateRKPii+0x5f): more undefined references to `__errno' follow --- In Boost-Users@yahoogroups.com, David Abrahams wrote: threads

library using gcc-nocygwin without doing any config steps. I'm very surprised that you needed to do it.

-- Dave Abrahams Boost Consulting www.boost-consulting.com

OK. But, now, do I need to run libs/config/configure to configure for gcc-nocygwin? Would I need to set any environment variables or command options to do that?

You shouldn't but if you do, then: export CXXFLAGS="-mno-cygwin" ./configure John.

"John Maddock" wrote in message news:018901c2775b$83735c20$4d3287d9@1016031671...

...

Unfortunately, bjam is somewhat limited by the underlying shell used to actually run the build commands. We've had a hard time getting it to cooperate with Win9x for that reason. John Maddock has had some success by building and running bjam under Cygwin, which has no command-line length limitation. I'm not sure whether it can be made to run the Borland toolset that way or not, but I know that John targets Borland so it's a good bet.

At one stage that did work, but not any more, the cygwin build will only build cygwin apps (it's a problem with the way in which cygwin passes absolute paths to the programs it spawns).

You can probably build all you want from the IDE pretty easily - many

I see. Pity. people

do that all the time.

Yes... I've been doing this all the time, but rather because I didn't take the time to learn how to use the build system. At least now I know how to interpret jamfiles, so I guess it will be easy to 'port them' to Borland makefiles. Thanks, -- Fernando Cacciola