When compiling a makefile with the BCB5 commandline tools, the linker gives me this error:
[exec] D:\PROGRA~1\Borland\CBUILD~1\Bin\..\BIN\ilink32 #MAKE0000.###
[exec] Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
[exec] Fatal: Unable to open file 'CONSTS.OBJ'
[exec] ** error 2 ** deleting lib\paslib.lib
I've checked all the files that get compiled and none of them use or make this file. The make file does not mention it. It is nowhere in the Borland program files. It is not even on my machine as far search can tell me. Predicibly of course, there are no problems when compiling in the IDE. What is this linker doing?
The project is called with make flags -B and -fproject.bpr
I suspect that one of the headers included in the source code has a line like this in it:
#pragma link "consts"
preprocess the .cpp files and you should be able to find where this is coming from.
There are other possibilities, but I think this is the most likely one.
Do you have a consts.dcu in the C:\Program Files\Borland\CBuilder5\Lib\Obj folder?
I don't know exactly what your error is, but perhaps it's related to this file, which is apparently a pre-compiled delphi unit.
I've not encountered this specific error before - but in case of doubt with weird errors from BCB, my first port of call is always to check the line endings of the files. It really, really wants CRLF line endings. Some stuff will appear to work with LF-only files, until some weird, impossible-seeming error in the middle of the file.
Maybe this isn't your problem, but it's certainly worth looking at.
Another thing you could try is to install Process Monitor from SysInternals. This will give you an idea which file it's looking for and where it's looking for it. It could be it's looking for consts.dcu (Delphi Compiled Unit - almost object code) and looking in the wrong place due to some mis-set path somewhere.
Related
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I am attempting to flash a basic hello world program to a Verifone terminal as an exercise in the development flow of the hardware. I'm currently running into an issue that is occurring somewhere during the post-build steps. After I build my project, I get the message:
***
*** The package '\Debug\dl.lab2.tar' is available for download.
***
Implying that the project built successfully. However, further up in the build messages, I can see:
"C:\Program Files (x86)\Verifone\PackageManagerProduction\Cygwin\tar.exe" -czf "usr1.bundle.lab2.tgz" "pkg.lab2.tar" "pkg.lab2.tar.p7s" "crt" -C "..\bundle" "./"
tar (child): gzip: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
And indeed, when I try to load the resulting archive, I get the "Invalid bundle file" on the PinPad. Inspecting the dl.lab2.tgz file shows that one of the internal archives is actually 0 Kb, so I'm quite positive it's because this archive generation step is failing. I'm not sure why it's failing though, because checking the directory contents, it seems like everything that it's looking for is there, though I can't explain why it's searching for "./". Does anyone have an idea why this is failing, and can someone tell me if it is possible to edit this archive generation step through CodeBench?
I figured out my answer to this, so I'll post an answer to hopefully help someone else in the future. I was correct in assuming that the error being returned by tar.exe was suspect. The post-build steps were being executed by running the external script simple_pkg.bat. Apparently the path in the simple_pkg.bat script was completely wrong; it was just pointing to an executable that didn't exist. Modifying simple_pkg.bat to point to where the correct tar.exe files was fixed my issue.
I'm looking at using Tesseract to do some work with PDF files, and so I want to use the library rather than an external executable.
I started by downloading the full Tesseract source and looking at building that. Sadly the standard sources don't have any means to build on a non-Linux platform, in my case Windows. There are methods for doing so, and I looked at those.
Firstly the VS2008 build doesn't. I'm aware that it need Leptonica, but I figured I'd tackle that afterwards and just tried to build the existing code. Fails with "fatal error C1083: Cannot open include file: 'allheaders.h': No such file or directory". Nothing to do with Leptonica at this stage, it simply doesn't work.
Even if I were able to get past that, I'd have to build Leptonica, and that requires using GNU tools and therefore an installation of Cygwin, so I gave up. I Have a MingW instatllation, (I've never managed to get Cygwin to work in a usable fashion) but I'm not keen enough to mess with such a complicated and fragile build.
So I decided I'd just use the pre-built binaries which some kind soul creates. Downloaded that from code.google.com. Now I need to look into using the code, so the next obvious step is the Tesseract API example, which states it requires "tesseract-ocr-3.02.02-win32-lib-include-dirs.zip", no problem, because I already have that now.
No real clue as to where the API example wants the files to be placed, but a little messing about gets them in appropriate locations. Press build and "fatal error C1083: Cannot open include file: 'allheaders.h': No such file or directory", just like trying to build Tesseract from source.....
And indeed there is no such file.
So, where is this file ?
I also struggled some time ago to make it works under windows and then I found this git repository : https://github.com/charlesw/tesseract-vs2012
It includes all needed extern library (because Tesseract need Leptonica, but Leptonica also need extern library to handle the different image format) and is also working great with vs 2013.
OK so now I see that allheaders.h is part of Leptonica. Still leaves me wondering why the Tesseract pre-built library requires that I have Leptonica available, I would have expected that to be built-in, I guess it isn't.
I've been trying to build some huge projects in BCB5 for some time now. I want to use the command line tools because it would cut build time by more than 50% (it already takes 4 hours in the IDE). Often, projects will build just fine in the IDE but fail miserably in the command line. I did some digging and discovered this nice little comment in a header file:
__published: // IDE-managed Components
Is this saying that the components that follow can only be built with the IDE open? Please tell me there is a way around this. BCB5 is starting to make me depressed.
Extra info:
Make.exe gives a pile of errors claiming ambiguity between the header file and an imported file. I''m pretty sure the header file is supposed to be referencing the imported file though, rather than comparing with it.
In the header file:
#include <ComCtrls.hpp>
ComCtrls.hpp has the variable TTreeNode.
Error from make:
[exec] Error E2015 .\TMain.h 876: Ambiguity between 'TTreeNode' and 'Comctrls::TTreeNode'
__published: // IDE-managed Components Is this saying that the
components that follow can only be
built with the IDE open? Please tell
me there is a way around this. BCB5 is
starting to make me depressed.
No, this does not mean that you can only build the source in the IDE. It just means that this section is automatically populated by the IDE (the form designer)
While there are good third party solutions (as mentioned by the others) C++Builder 2007 and above made huge improvements in the build system. IDE build times are very similar to command line builds and the MSBuild integration now makes it possible to be sure that the same parameters are passed to the command line tools as are used by the IDE.
Have you tried installing the C++ Compiler Enhancements plugin, by Andreas Hausladen, which improves the compilation speed. I would also recommend installing the DelphiSpeedUp plugin.
I think you need to export the project as makefile, to compile from the command line, because C++Builder 5 project files are XML. Have a look at this article, from the C++Builder Developer's Journal.
If none of the above fails try the official C++Builder Forum.
I've more or less given up on the BCB5 command line tools. It appears that they are fundamentally broken.
I did, however, manage to find a nice open source tool, ProjectMaker, that uses the command line tools effectively. You can find it here: http://projectmaker.jomitech.com.
ProjectMaker fixes up a few of the problems with BPR2MAK, but it's not perfect. Most project build perfectly with ProjectMaker, some still require the IDE. It's not a perfect solution, but it does alright.
I have been used to working with VS2005 and 2008 - using msbuild, etc, but I have inherited a set of projects that have to remain in vc6.0 for now. I don't like opening each project in the developer studio and building. I prefer to build form command line (I am automating the builds). Is this possible?
I have tried the nmake utility, but I still need to open up the projects and save/export the make file. This is tedious if the project changes - each time I have to save the make file. nmake seems to work, but it had a problem when I changed the location of the project in my directory tree (I checked out of svn into a new clean dir to try the build). It seemed to have hard coded paths in it, but I will have to check on that - it might have been a different problem.
Any alternatives out there?
Eventually I will migrate these to 2008, but for now that is not an option.
I'm recording the most important part of your link here - Microsoft has a bad habit of moving stuff around and leaving dead links. Not only is this the most important bit, but it gives enough information to do a search if/when they move it.
Building a Project from the Command Line
You can build a Visual C++ project from the command line without first exporting a makefile (MAKEFILE, or filename.mak) and using the NMAKE utility.
The basic command syntax is
msdev FileName [/MAKE "ProjectName – ConfigName | ALL"] [/REBUILD /CLEAN /NORECURSE /OUT LogFile /USEENV]
where FileName is the name of your project (.dsp) or workspace (.dsw) file.
I think I found m answer here:
http://msdn.microsoft.com/en-us/library/aa699274.aspx
thanks all
of course you can automate. I haven't used vc in years, but I think the compiler is called c8.exe or wow, I can't remember silly little tidbits like that anymore, but look in your vc\bin directory at all the exes and it will be obvious by name.
you can write a batch file worst case. But I also remember the UI having a "create makefile" function. So you do that once, and then just run make from the command line and voila. or maybe it's nmake. Again, been a long long time.
Microsoft provides a command line driver for building Visual Studio projects. In VC6 it's called "msdev" (do msdev /? for a list of options).
At some point (probably VS.NET/VS 2002) they started calling the command line build driver "devenv" for some reason. It has a somewhat different syntax, but for driving builds the options are the same or similar.
We use automated builds at my work place. Essentially just a batch file i fire off from the command line. Let me make sure i am allowed to post some sample code before i go ahead and post it. But yes, it IS possible to automate the build.
Sample Code:
:::::::: CompileSolution :::::::::::::::::::::::::
call X:\BuildTools\bin\BuildVbProj.bat
%COMPONENTNAME% %SOLUTIONDIR%
%PROJFILE% %BUILDOUTPUTFILE%
%PREBUILDFILE% if %ERRORLEVEL% NEQ 0
goto BuildErrors
goto Cleanup
EDIT: The BuildVbProj.bat file ultimately calls VB6.exe in the Program Files\MS Visual Studio\VB98\ folder. Try calling it with "VB6.exe /?" or "VB6.exe -?" and it will show you a list of options. You can basically automate your process using those options.
There should be a similar exe for VC in the VC98 folder as well.
Another option which is less labor intensive is
Pulldown Menu (BUILD)
Select (BATCHBUILD)
Push Button (REBUILDALL)