I know that are similar question but doesn't help me.
I want to build boost for Windows CE 6 on an x86 Platform.
I've build STLPort in release moded as shared library for WINCE with success, I've also add some patch and integrate the OpenCE Time library and implemented some missing ANSI C function. STLPort test is ok (just an issue with wcout, wcin and wcerr in_avail() function, I don't know exactly where is the problem).
To build boost I created a batch file and change the user-config.jam in this way. The build is ok but seems that I'm compiling for my Windows Xp Platform instead of WinCE.
The boost build system is very complicated and I'm not understanding how it work (the documentation isn't very good and on google there's no much). The build of boost is ok but I cannot run application. It seems that is missing some DLL or that the Boos DLL's are wrong. The message I get when I'm attacched with debugger is "Nessun processo all'estremita' della PIPE" -> "No process at the end of the PIPE". When I try to launch the application from the target device it has no effect. Am I wrong something? How can I tell boost to use specific configuration?
Another problem is that i cannot see the build log. I don't know what exactly I'm building. Is there a way to see what actually is done?
The batch file that I call to build boost (I start the shell of Visual Studio 2008):
#echo off
cls
bjam --with-chrono --with-date_time --with-thread toolset=msvc-CEPlatformName variant=release threading=multi link=shared runtime-link=shared
This is the user-config.jam located in tools/build/v2
using msvc : CEPlatformName:
<compileflags>-D_CRT_SECURE_NO_WARNINGS
<compileflags>-D_CRT_SECURE_NO_DEPRECATE
<compileflags>-DBOOST_PROTO_MAX_ARITY=10
<compileflags>-DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
<compileflags>-DBOOST_MPL_LIMIT_METAFUNCTION_ARITY=10
<compileflags>-D_WIN32_WCE=0x600
<compileflags>-DUNDER_CE
<compileflags>-DWINCE
<compileflags>-Dx86
<compileflags>-D_x86_
<compileflags>-D_UNICODE
<compileflags>-DUNICODE
<linkflags>/subsystem:windowsce,6.00
<linkflags>/MACHINE:X86
<linkflags>/NODEFAULTLIB:oldnames.lib
<linkflags>/NODEFAULTLIB:libc.lib
<linkflags>coredll.lib
<linkflags>corelibc.lib
<linkflags>ole32.lib
<linkflags>oleaut32.lib
<linkflags>uuid.lib
<setup>C:/boost_1_53_0/CEPlatformNameConfig.bat.bat
;
using stlport : 5.2 :
C:/celib/stlport/stlport :
C:/celib/stlport/bin
;
And this is the script file for configuration
#echo off
echo CONFIGURAZIONE PER LA COMPILAZIONE DI BOOST SU WINCE
echo.
rem ------------------------------------------------------------
set BOOST_DIR=c:\boost_1_53_0\boost
set PLATFORM=CEPlatformName
set TARGETCPU=x86
set OSVERSION=WCE600
set STLPORT_DIR=C:\celib\stlport
set STLPORT_INC=%STLPORT_DIR%\stlport
set STLPORT_LIB=%STLPORT_DIR%\bin\%PLATFORM%
rem ------------------------------------------------------------
if not %1==%&TARGETCPU% goto error
echo Setting Boost directory to %BOOST_DIR%
echo Setting OS Platform to %PLATFORM%
echo Setting target CPU to %TARGETCPU%
echo Setting OS Versione to %OSVERSION%
echo Setting STLPORT_INC to %STLPORT_INC%
echo Setting STLPORT_LIB to %STLPORT_LIB%
rem settin visual studio 2008 variable path
set SDKROOT=C:\Programmi\Windows CE Tools
set PATH=%VSINSTALLDIR%\VC\ce\bin\x86_cex86;%VSINSTALLDIR%\VC\bin;%VSINSTALLDIR%\Common7\IDE;%PATH%
set PLATFORMROOT=%SDKROOT%\%OSVERSION%\%PLATFORM%
set INCLUDE=%STLPORT_INC%;%PLATFORMROOT%\include\;%PLATFORMROOT%\include\%TARGETCPU%;%VCINSTALLDIR%\ce\include;%VCINSTALLDIR%\ce\atlmfc\include;%VSInstallDir%\SmartDevices\SDK\SQL Server\Mobile\v3.0;
set LIB=%STLPORT_LIB%;%PLATFORMROOT%\lib\%TARGETCPU%;%VCINSTALLDIR%\ce\ATLMFC\LIB\%TARGETCPU%;%VCINSTALLDIR%\ce\LIB\%TARGETCPU%
echo PATH at %PATH%
echo.
echo INCLUDE is %INCLUDE%
echo.
echo LIB is %LIB%
echo.
goto exit
:error
echo Invali Target CPU
goto exit
:exit
echo impostazioni avvenute con successo
EDIT
Seems that the compileflags in the user-config.jam has no effect... or better seems that the user-config.jam has no effect
EDIT 2
I've found an issue
using msvc : CEPlatformName :
<compileflags>-D WINCE
The issue is that this instruction does not define anything. I've also tried
using msvc : CEPlatformName :
<compileflags>/D_CRT_SECURE_NO_WARNINGS
But the result is the same.
I've found the problem
I'm finally build boost.chrono boost.date_time boost_system and boost.thread fow Windows CE 6.0 on a custom x86 target.
I've changed user-config.jam in this way
using msvc : 9.0~CEPlatformName : "C:\...\cl.exe" :
<compileflags>-D_CRT_SECURE_NO_WARNINGS
<compileflags>-D_CRT_SECURE_NO_DEPRECATE
...
<setup>CEPlatformNameConfig.bat
;
in this way the bjam call the correct batch file for configure the build system. If the compiler is not specified bjam will call vcvarsall.bat and the compiler flags will be ignored.
Now the bjam call is:
bjam ... toolset=msvc-9.0~CEPlatformName ...
It's also important to correctly define the `x86` and `_X86_`. Note that `X86` will casue STLPort to assume wrong directory for ANSI C library files.
But I've an Issue on boost::this_thread::sleep_for() function. I know that boost use TLS for this operation and I know that TLS is not fully implemented in WinCE. I can replace this function with a simple ::Sleep() of the Win32 Library.
I'm only sure the WinCE has `TlsAlloc()`, `TlsFree()`, `TlsGetValue()` and `TlsSetValue()` functions, and has at least `TLS_MINIMUM_AVAILABLE` slot for TLS that is defined at least to 64.
Finaly I'm able to build Boost.Thread Boost.System Boost.Chrono Boost.DateTime Boost.Regex in debug and release mode.
The issue is according to this port (http://stackoverflow.com/questions/16016637/boost-c-and-windows-ce-6-0) that WinCe doesn't support long names. DLL name's can be larger then 32 chars.
The same problem of name length caused this_thread::sleep_for to don't work.
Thanks for all people the helped me.
Related
I tried to build mysql-connector-c++ from source to static library.
Referring the official spec here, I generated the Visual studio solution by the following command:
cmake -DMYSQL_DIR="E:\mysql-5.7.21-winx64" -DWITH_BOOST="E:\libs\boost_1_67_0_BUILDED" -DWITH_JDBC=ON -G "Visual Studio 15 2017 Win64" ../
Then, I opened the vs solution generated by cmake.Run build, got the two libs: mysqlcppconn8-static-mt.lib, mysqlcppconn-static-mt.lib, and copied them to my project.
When I built my project (also vs2017 version), I got the error:
mysqlcppconn-static-mt.lib(net_serv.obj) : error LNK2038: 检测到“_MSC_VER”的不匹配项: 值“1800”不匹配值“1900”(ActionProcessor.obj 中)
I am confused. They're all built in vs2017, and platform toolset are all set to "Visual Studio 2017 (v141)". I can't understand where 1800_MSC_VER has come from.
Here is what I did
Specs
Visual Studio 15, (2017)
x64
Static (.lib)
With static runtime (/MT)
Tools
CMAKE
Bison (In a folder without spaces)
Perl (ActiveState or Strawberry)
OpenSSL 1.0.2q.tar.gz
Add CMAKE, Bison and pearl to your system path
Check to see if you got all setup correctly
C:\>cmake --version
cmake version 3.9.6
C:\>bison --version
bison (GNU Bison) 2.4.1
C:\>m4 --version
m4 (GNU M4) 1.4.13
C:\>perl -version
This is perl 5, version 24, subversion 3 (v5.24.3)
Step 1: Build OpenSSL 1.0.x
Note: if you want to build OpenSSL 1.1.x steps will be a bit different
Extract to: C:\mysql-8.0.15\openssl-1.0.2q
Run: x64 Native Tools Command prompt for VS 2017
cd C:\mysql-8.0.15\openssl-1.0.2q
Release
perl Configure VC-WIN64A no-shared --openssldir=.\rel64
ms\do_win64a
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
Debug
nmake -f ms\nt.mak clean
perl Configure debug-VC-WIN64A no-shared --openssldir=.\dbg64
ms\do_win64a
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
Step 2: Build MySQL (Yes the actual database)
Extract to: C:\mysql-8.0.15
Run: x64 Native Tools Command prompt for VS 2017
cd C:\mysql-8.0.15\
cmake . -G "Visual Studio 15 2017 Win64" ^
-DWITH_BOOST=C:/mysql-8.0.15/boost ^
-DDOWNLOAD_BOOST=1 ^
-DBUILD_CONFIG=mysql_release ^
-DWITH_SSL=C:\mysql-8.0.15\openssl-1.0.2q\rel64 ^
-DLINK_STATIC_RUNTIME_LIBRARIES=1
Copy m4.exe to C:\mysql-8.0.15\sql\ this avoids any m4.exe errors during built
Open MySQL.sln and build for release x64
Copy binary_log_funcs.h and binary_log_types.h from mysql-8.0.15\libbinlogevents\export to mysql-8.0.15\include
The library should be located at:
Static release library: C:\mysql-8.0.15\archive_output_directory\Release\mysqlclient.lib
Step 3: Build MySQL Connector C++
Copy C:\mysql-8.0.15-dbg\archive_output_directory\Debug\mysqlclient.lib
to C:\mysql-8.0.15-dbg\lib\vs14
Run CMAKE GUI
Browse to the path of the MySQL Connector Project.
Click Configure, Select Visual studio 15 2017 Win64, native compilers
Tick BUILD_STATIC
Tick STATIC_MSVCRT
TICK WITH_JDBC
remove WIN_SSL_YASL from CONFIG_VARS
WITH_SSL = C:\mysql-8.0.15\openssl-1.0.2q\rel64
WITH_BOOST= C:\mysql-8.0.15\boost\boost_1_66_0
MYSQL_DIR=C:\mysql-8.0.15
Open MySQL_CONCPP.sln build for Release x64
The library is located at:
C:\mysql-connector-c++-8.0.15\jdbc\install\lib\mysqlcppconn-static-mt.lib
C:\mysql-connector-c++-8.0.15\Release\mysqlcppconn8-static-mt.lib
Step 4: Test it
Note: This test is for the JDBC style API. If you are not maintaining an existing application, use the new xdevapi API.
Create a new project and put the following in main.cpp
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#define STATIC_CONCPP
#define CONCPP_BUILD_STATIC
#define CPPCONN_PUBLIC_FUNC
#include <driver.h>
#include <connection.h>
#include <statement.h>
#include <exception.h>
sql::Driver *mDriver;
sql::Connection *mConnection;
int main() {
mDriver = get_driver_instance(); //or use: new MySQL_Driver()
try {
mConnection = mDriver->connect("host", "username", "password");
mConnection->close();
}catch(sql::SQLException& ex) {
std::cout << ex.what();
}
delete mConnection;
return 0;
}
Set: Linker > Input > Additional Dependecies:
libeay32.lib;mysqlclient.lib;mysqlcppconn8-static-mt.lib;mysqlcppconn-static-mt.lib;ssleay32.lib;%(AdditionalDependencies)
Set: Configuration Properties > VC++ Directories
Include Directories.
Library Directories.
I don't even know where to start explaining to be honest. Building this was a massive pain.
Before you begin to read this, please ensure you have the following:
C:\boost
C:\OpenSSL-Win32
C:\OpenSSL-Win64
Because I was writing my own "wrapper" and trying to make UNICODE work properly, I was getting weird exceptions, and I was unable to debug anything because I downloaded the latest package which is built without debug information (https://dev.mysql.com/downloads/connector/cpp/)
This is the first time I try to build this, so I went to their Github repository and grabbed the latest "master": https://github.com/mysql/mysql-connector-cpp
BUT! This does not contain the "JDBC" sources, which is by the way the "native" connector as they call it. So I grabbed it from the branch: https://github.com/mysql/mysql-connector-cpp/tree/jdbc and then copied the files into "mysql-connector-cpp-master\jdbc".
OK. I opened "x64 Native Tools Command Prompt for VS 2017" and navigated to "mysql-connector-cpp-master". At this point I still had no idea what I am doing and how to build it, all I could understand from the docs and different articles here is to run:
cmake -DWITH_JDBC=ON --build .
This started to configure things and build OK, but it stopped here:
-- Searching for static libraries with the base name(s) "mysqlclient"
CMake Error at FindMySQL.cmake:524 (message):
Could not find "mysql.h" from searching "/usr/include/mysql
/usr/local/include/mysql /opt/mysql/mysql/include
/opt/mysql/mysql/include/mysql /usr/local/mysql/include
/usr/local/mysql/include/mysql C:\Program Files/MySQL/*/include
C:/MySQL/*/include"
Call Stack (most recent call first):
CMakeLists.txt:332 (INCLUDE)
OK. So what now... where is "mysql.h" ?! After searching... and searching, I found this: Missing mysql.h and trying to find mysql-devel
And I quote:
Grab the MySQL Community Server and install it on your system. It
contains a directory called include in which you find the mysql.h.
Ok, great we need more stuff. So I download: https://dev.mysql.com/downloads/mysql/ and run the command again.
Happy days, something happened but no libs yet. I did get however a VS 2017 solution called: "MYSQLCPPCONN.sln".
This contains VS 2017 configuration to build the library for Win32. And of course trying to build with this solution will give you A LOT of unresolved external symbols.
So I run again the cmake but with static option added:
cmake -DWITH_JDBC=ON -DBUILD_STATIC=ON --build .
This time when I open "MYSQLCPPCONN.sln" I can see another project "mysqlcppconn-static" and this builds fine without issues.
However, in my case I need x64. I just created a new configuration for x64 by copying the exiting configuration fron Win32.
So that's it, I have both Win32 and x64 "mysqlcppconn-static.lib".
Overall Conclusion at this time:
Quite hard to build, without experience you will spend some time...
time.
No proper documentation, their existing documentation is poorly
written and very confusing.
No UNICODE support, yes the projects compile as Multi-Byte
Character Set.
I will see if I can debug and find out why am I getting exceptions in the library when using this (from their documentation):
sql::ConnectOptionsMap connection_properties;
connection_properties["hostName"] = "";
connection_properties["port"] = "";
connection_properties["userName"] = "";
connection_properties["password"] = "";
connection_properties["schema"] = "";
connection_properties["OPT_CONNECT_TIMEOUT"] = 10;
connection_properties["CLIENT_MULTI_STATEMENTS"] = (true);
connection_properties["OPT_CHARSET_NAME"] = "utf8";
connection_properties["OPT_SET_CHARSET_NAME"] = "utf8";
I hope you can build your library with this information, and hopefully in the future it will become more easier and clear.
Good Luck.
I'm following this guide on building V8 but I am hitting some issues on the compilation step. I am running Windows 10 x64. I am trying to compile with options to embed the engine also.
Running the following command:
ninja -C out.gn/x64.release
Gives me this error:
ninja: Entering directory `out.gn/x64.release'
[1/471] LINK mksnapshot.exe mksnapshot.exe.pdb
FAILED: mksnapshot.exe mksnapshot.exe.pdb
C:/Workspace/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x64 False link.exe /nologo /OUT:./mksnapshot.exe /PDB:./mksnapshot.exe.pdb #./mksnapshot.exe.rsp
LINK : fatal error LNK1181: cannot open input file 'comdlg32.lib'
ninja: build stopped: subcommand failed.
Now I believe I have narrowed down the error to looking for the .lib files in the wrong directory. I have (had) multiple versions installed, so there were multiple folders in my Windows Kit install.
Windows Kits/10/Lib/10.0.16299.0
Windows Kits/10/Lib/10.0.15xxx.0
If I dragged and dropped the comdlg32.lib file from 10.0.16299.0 into the 10.0.15xxx.0 directory then the error changed to a LNK1181 error with a different input file. I did this a few times but I was unsure if this was going to cause issues with different versions and there was probably going to be a lot.
I uninstalled the 10.0.15xxx.0 version which left behind the folder I mentioned, so I removed that and after doing so I have started getting the LNK1181 error with a different input file (advapi32.lib I assume the very first file it can't find). This is how I came to the conclusion about the path being incorrect.
So I have tried a few things to change the path (I hoped just uninstalling the old version would fix it) such as:
Uninstalling the old version.
Going through registry entries to see if I can find an install path or something using that path, which I didn't. I did notice that there was still installation and data in the registry for the 10.0.15xxx.0 install, I might try deleting that from the registry directly as a last resort?
I have tried to explicitly set the path by setting <TargetUniversalCRTVersion>10.0.16299.0</TargetUniversalCRTVersion> in this file: C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\uCRT.props
I have never used Ninja before so I tried looking for a way to set some kind of lib-path in the command but couldn't really find anything.
I looked through the python scripts being executed to try and locate something to do with the libs path but couldn't see anything.
I would be grateful for any help and suggestions. Thanks.
You can try to compile v8 using Visual Studio as explained here: https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#using-the-visual-studio-ide
By running the following commands:
$ gn gen --ide=vs out.gn/x64.release
$ cd out.gn/x64.release
$ msbuild all.sln
You can see a full example here: https://github.com/phpv8/v8js/issues/272#issuecomment-262848754
Apparently this method is not officially supported anymore, but I had the same problem as you have and this solved the issue for me.
Note that after this I had another issue, the unit tests failed to be compiled due to a linking error, but I had the necessary libraries to use v8. So there may be deeper problem that is causing all of this that I'm missing.
Edit:
Also, you could try to set the following parameters with gn args:
visual_studio_path = "..."
visual_studio_version = "2017"
wdk_path = "..."
windows_sdk_path = "C:\Program Files (x86)\Windows Kits\10"
To set those parameters, do:
gn args out.gn/x64.release
This will open a text editor where you can write the extra parameters you are interested in.
To see the full list of parameters you can specify:
gn args --list out.gn/x64.release
I was following this guide https://medium.com/dailyjs/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4 and also ran into the error
LINK1181: cannot open input file 'advapi32.lib'
I'm pretty sure it was because I had the wrong versions of the Windows 10 SDK. Similar to you I had versions:
Windows Kits/10/Lib/10.0.10240.0
Windows Kits/10/Lib/10.0.16299.0
But according to https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Setting-up-Windows (Which I think is relevant) you need version 10.0.15063.0
After installing version 10.0.15063.0 (with the visual studio installer) to
Windows Kits/10/Lib/10.0.15063.0
I was able to continue with the build.
When I'm compiling ism project to create MSI, its still creates the MSI even though I have build errors.
The reason I need it NOT to be created is for build verification.
Instead of checking the build log for errors, I will just check the existence of the MSI.
Does anybody know how can I achieve that?
EDIT:
I'm using ISCmdBld tool to build MSIs. This is the command line I'm running to build where the environment variables are being set before running this command:
IsCmdBld -p "%FULL_PROJECT_FILENAME%" -a %BUILDMODE% -r %PRODUCT% -o "%MMSEARCHPATH%" | tee /A "%FULL_PROJECT_LOG_FILENAME%"
If you are compiling using IsCmdBld.exe, you should add the -x option, so that the build is stopped if an error occurs.
You also can use it combined with -w, which makes each warning becomes considered as an error (and thus, each warning encountered also stops the build).
More information about IsCmdBld.exe : http://helpnet.installshield.com/installshield16helplib/ISCmdBldParam.htm
I hope this helps.
Your build automation should check the exit code from ISCmdBld.exe. If the exit code is a failure, don't archive the output.
Its kinda an odd story. I'm trying to build the openssl library. Well, it is not the first time I'm doing it and until now it was fine. however, I've desided to add a build configuration to TeamCity (actually the problem has nothing to do with TeamCity)to build all my third parties libraries on-demand. So, I created a step with common set of openssl build commands:
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake /d /f ms\ntdll.mak
... and the build failed while assembling the very first asm file. So I ran same commands in VS2012 x64 command prompt and the build succedeed, as expected. It took a while untill I figured out that the problem is in output redirection. Teamcity redirects output from build step to the teamcity build log, so did I by adding ">1.txt" to "nmake /d /f ms\ntdll.mak" command, and the build failed. I would say it is somewhat unexpected reason for build to fail.
So far, I've tried:
Building the same from VS2010 command prompt with redirection,
failed.
Building the same from VS2010 command prompt without
redirection, succeded.
Building the same from VS2010/VS2012 command
prompt with redirection to file and forcing redirection to CON (nmake
/d /f ms\ntdll.mak >CON >1.txt) failed.
Googling for "nmake problems
when console output is redirected" - nothing
Googling for "openssl
build problems when console output is redirected" - nothing
My setup
- Win2008R2, virtual machine.
- VS2010, latest updates
- VS2012, Update 1
Actual error:
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\amd64\ml64.EXE"' : return code '0x1'
ml64.exe complains about the asm file stating it should end with "END" statement. It does, but...
Any ideas?
Ok, since the problem is in perl and writing files to stdout and then redirecting it you have to change following files to build x64 version:
crypto\aes\asm\aes-x86_64.pl
crypto\bn\asm\modexp512-x86_64.pl
crypto\bn\asm\x86_64-gf2m.pl
crypto\bn\asm\x86_64-mont.pl
crypto\bn\asm\x86_64-mont5.pl
crypto\md5\asm\md5-x86_64.pl
crypto\modes\asm\ghash-x86_64.pl
crypto\rc4\asm\rc4-md5-x86_64.pl
crypto\rc4\asm\rc4-x86_64.pl
crypto\sha\asm\sha1-x86_64.pl
crypto\sha\asm\sha512-x86_64.pl
crypto\whrlpool\asm\wp-x86_64.pl
crypto\x86_64cpuid.pl
engines\asm\e_padlock-x86_64.pl
you have to open these files and change all "open STDOUT "whateverfile"" to something like "open my $asmfile "whaeverfile"", then take care of string concatenation (only in x86_64cpuid.pl) and then print it to the file instead of STDOUT, something like "print $code" to "print $asm $code"
and of course, dont forget to close the file, in another words change the "close STDOUT" to "close $asmfile"
Obviously when building target other than x64 one will have to change another set of files.
Will try to communicate it to openssl maintainer.
I have a batch file that tries to compile a static library using Borland C++ Builder 6.0
It is called from Borland make (makefile created with bpr2mak) which is called from a .bat file (used to compile the whole project with Visual Studio and some Borland C++ Builder legacy projects), which is called from a bash shell script running inside Cygwin.
When I run the .bat file directly from a Cygwin shell, it runs OK, but when its being run from a Program calling cygwin with Boost::Process::launcher I'm getting this error:
C:\ARQUIV~1\Borland\CBUILD~1\Bin\..\BIN\TLib /u bclibs.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting bclibs.lib
It's a complicated scenario, but this Program which calls cygwin is run whenever we need to build our software package which needs to be build for various Linux distos and Windows 32 and 64-bit.
Note: It's the only Borland Project failing, the other compile just fine (it's the only static library using borland also, so it can be some problem with the TLib tool.
The problem was that TLib does not like to have his output redirected (seen here) without having an input pipe as well. Solved by creating an input pipe to in the Boost::Process::launcher using set_stdin_behavior
I'm just guessing here, but this may have to do with long filenames and/or spaces in paths.
1) Modify your makefile so it would save current environment to a file, immediately before executing the failing command (set > d:\env.txt & echo CD=%CD% >> d:\env.txt). Then run it both ways (directly and via program) and compare the environments of good run and bad run.
2) Using filemon from Sysinternals, capture logs of disk access in both cases (these logs are going to be huge, though you can uncheck everything except Open in the filter to reduce the size). Again, compare and check for clues...
3) Try instaling everything involved to paths conforming to 8.3 scheme.
This error is not related to C++ itself. It happens when your build script opens too much files (more than defined in DOS command processor environment). To resolve this issue try to set value of files variable to 253. For Windows XP this variable defined in the file %WINDIR%\system32\config.nt.
files=253
Seems it is known bug in Borland C++ tools. Here is description and possible workaround for this issue:
Problem: Some static Lib projects will
not link correctly when compiled. You might see something
like this :
J:\Borland\CBUILD~1\bin\..\BIN\TLib /u debug\jpegD.lib #MAKE0000.###
DOS-reported error: Bad file number
TLIB 4.5 Copyright (c) 1987, 1999 Inprise Corporation
opening 'MAKE0000.###'
** error 1 ** deleting debug\jpegD.lib
MAKE failed, returned : 1
Workaround : In some cases (where the "Bad file number" error is seen) it may be possible to work around this by specifying -tDEFLIB.BMK in the BPR2MAKE Options field, and Turning off the "Capture Make Output" option.
I have not tested it, but I hope that helps.