after much digging i finally came accross this thread: Does the .res file need to be in source control? which we never included it in git from the get go. Now I'm trying to build the project from the source from the command line. If i open the file in Borland it will ask me to recreate said file and I can go about making the project. If I delete all generated files and rake I get the following output (exploded the ruby task for clarity)
$ bpr2mak_exe="#{ENV['BCB']}\\Bin\\bpr2mak.exe"
$ make_exe="#{ENV['BCB']}\\Bin\\make.exe"
$ puts `#{bpr2mak_exe} -omakefile MyProject.bpr`
Loading project file
Loading template
Generating Makefile
.........................................
& puts `#{make_exe} -fmakefile`
MAKE Version 5.2 Copyright (c) 1987, 2000 Borland
Fatal: 'MyProject.res' does not exist - don't know how to make it
I looked at all the command line tools (focused on BRCC32.exe and GRC32.exe) and neither of them look like what I need. I also tried using procmon to see what program is called to generate the res file. So any of you Borland/Embarcado people want to pipe up? (here are the command line help screens if it helps)
$ "${BCB}\bin\BRC32.exe" -?
Syntax: BRC32 [options ...] filename
options marked with a '*' are on by default
-r compile only. Do not bind resources
-fofilename set output res filename
-fefilename set output exe filename
-v verbose
-ipath set include path
-x ignore INCLUDE environment variable
-dname[=string] define #define
-32 * build 32-bit Windows compatible res/exe files
-16 build 16-bit Windows compatible res/exe files
-Vd.d Mark the .exe file with Windows version provided (4.0 is the default)
-31 Provided for downward compatibility (build 16-bit res/exe files)
-w32 Provided for downward compatibility (build 32-bit res/exe files)
-k do not create fastload area (16 bit only)
-t (ignored, for compatibility)
-? or -h display this message
$ "${BCB}\bin\BRCC32.exe" -?
Borland Resource Compiler Version 5.40
Copyright (c) 1990, 1999 Inprise Corporation. All rights reserved.
Syntax: BRCC32 [options ...] filename
options marked with a '*' are on by default
#<filename> Take instructions from command file
-r (ignored for compatibility)
-16 Build 16-bit Windows compatible .res file
-32 * Build 32-bit Windows compatible .res file
-fofilename Set output filename
-v Verbose
-ipath Set include path
-dname[=string] Define #define
-x Ignore INCLUDE environment variable
-m Enable multi-byte character support
-cdddd set default code page to nnnn
-lxxxx set default language to xxxx
-31 Provided for downward compatibility (build 16-bit .res file)
-w32 Provided for downward compatibility (build 16-bit .res file)
-? or -h Display this message
and just for fun I tried running them against the project file
$ "${BCB}\bin\BRC32.exe" -r MyProject.bpr
Borland Resource Compiler Version 5.40
Copyright (c) 1990, 1999 Inprise Corporation. All rights reserved.
Error MyProject.bpr 1 1: Expecting resource name or resource type name
$ "${BCB}\bin\BRCC32.exe" -r MyProject.bpr
Borland Resource Compiler Version 5.40
Copyright (c) 1990, 1999 Inprise Corporation. All rights reserved.
Error MyProject.bpr 1 1: Expecting resource name or resource type name
The IDE, not the compiler, generates the default .res file using version information extracted from the project file. For what you are attempting for a command-line compilation, you are better off creating your own .rc script file with the required resource data definitions, and then compile that to a .res file using brcc32, and then you can link to it with ilink32.
But, you really shouldn't be using make to compile a Borland project to begin with. Use Borland's bcc32 compiler, or MS's msbuild framework (depending on your version of C++Builder) and let it handle everything that make would do. Then you can compile your .bpr or .cproj file without having to convert it to a .mak file first.
Related
I tried this command:
gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceRGB -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=/tmp/test/pdfa/pdftopdfa.pdf /tmp/test/pdftopdfa.pdf
But I got this error:
Artifex Ghostscript 9.14: Can't find initialization file gs_init.ps.
I tried another command:
gs -dPDFA -dBATCH -dNOPAUSE -dUseCIEColor -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=/tmp/test/pdfa/23238input.xml_2.pdf 23238input.xml_2.pdf
But i got this error:
Artifex Ghostscript 9.14 (2014-03-26) Copyright (C) 2014 Artifex
Software, Inc. All rights reserved. This software comes with NO
WARRANTY: see the file PUBLIC for details. Can't find (or open)
initialization file (gs_std_e.ps) Unrecoverable error: undefined in
.uninstallpagedevice Operand stack: gs_std_e.ps gs_std_e.ps
gs_std_e.ps
Well firstly you are using an old version of Ghostscript, you should probably upgrade.
Secondly wherever you got it from, its non-standard because it has the PostScript resources stored on disk, the default is for them to be built into the binary as a ROM file system.
Finally it appears that the resources on disk are either missing or corrupted. You could search for them, they are usually in somewhere like /usr/local/bin/ghostpdl/Resource and then use the -I switch to present that path to Ghostscript so it knows where to look.
But since its an old version then I'd suggest you get the current version (9.21) instead. If you get a package, and that fails to work, then you should complain to the package maintainer. If you feel up to it you can simply clone the Ghostscript Git repository and build it yourself, its not hard if you have a working C compiler (gcc). Lastly, there are pre-built Linux binaries here which may work on your system, depending on what your setup is.
A couple of notes on your command line; you have not specified the PDFA_def.ps file which you will have to do in order to create a valid PDF/A file, see this documentation but note that's the current 9.21 docs. If you don't supply that file (properly modified from the supplied model) then you won't be able to create a conforming PDF/A file.
Do not use -dUseCIEColor unless you have a very good reason, if you don't know what it does (and I'm guessing you don't) then you don't have a good reason. If you use it without understanding you'll only adversely impact performance and possibly get poor colour reproduction.
I am trying to build openssl libs. I cloned a repo from GitHub https://github.com/openssl/openssl
And now using a "command line" of Visual Studio 2013. This command line:
I use next commands:
cd C:\Programs\openssl - go to the folder with openssl repo
perl Configure VC-WIN64A --prefix=C:\Programs\openssl-build - actually, I have no idea what this command exectly do, but all manuals talks it need. This command has next output
And "Yes, I have 'Perl', of course I installed 'Perl'"
And the next (and the last) command, which I write ts just simple "nmake". The last becouse the output of this command has some "fatal errors", which doesn't let me continue installation
As you see, the main error is "fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'". As I know, the parametr machine type can be supplied in properties of Solution in Microsoft Visual Studio GUI, but how to set it from command line I have no idea, and openssl doesn't represented by Microsoft Visual Studio Solution, which can be open by MS Visual Studio.
So, maybe somebody knows how to set this property from command line, or, maybe, this error doesn't depends from this and somebody know how to solve this problem.
I hope for your help. Please, guys, second day I try to solve this, you are my last chance!!
Here is what I did. First, I opened a command prompt for 64-bit builds:
$ cl
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64
Then, I downloaded the current 1.1 release tarball. There is no reason to mess with development versions unless you are actually developing OpenSSL and you are capable of debugging problems in development versions.
$ curl -O https://www.openssl.org/source/openssl-1.1.0e.tar.gz
$ tar xvf openssl-1.1.0e.tar.gz
$ cd openssl-1.1.0e
At this point, I read INSTALL which I recommend you also do instead of saying "I have no idea what this command exectly do". Once you read INSTALL, you will know what the command actually does.
$ perl Configure --prefix=%TEMP%\openssl VC-WIN64A
$ nmake
This gave me no errors, so I went ahead and issued
$ nmake test
which gave me
Microsoft (R) Program Maintenance Utility Version 12.00.21005.1
Copyright (C) Microsoft Corporation. All rights reserved.
set SRCTOP=.
set BLDTOP=.
set PERL=C:\opt\perl\5.24.1\bin\perl.exe
set OPENSSL_DEBUG_MEMORY=on
"C:\opt\perl\5.24.1\bin\perl.exe" ".\test\run_tests.pl"
test\recipes\01-test_abort.t ............ ok
test\recipes\01-test_sanity.t ........... ok
test\recipes\01-test_symbol_presence.t .. ok
...
test\recipes\90-test_sslapi.t ........... ok
test\recipes\90-test_threads.t .......... ok
test\recipes\90-test_v3name.t ........... ok
All tests successful.
Files=91, Tests=433, 100 wallclock secs ( 0.66 usr + 0.27 sys = 0.92 CPU)
Result: PASS
At this point, I am pretty certain nmake install would also have worked, but I did not want to replace anything on my system.
You do not have a Perl or programming related problem.
I think you forgot to run the ms\do_ms.bat file produced by the Configure script.
Below is the script that I use for building OpenSSL on my PC.
Prerequisites:
Install Perl on your PC. I think I used ActivePerl, but I suspect any version will do.
Install NASM. http://www.nasm.us/
Install Visual Studio
Then save the following script to file called bldenv.cmd
REM ######################################
REM MODIFY THESE VARIABLES BELOW TO POINT TO YOUR NASM, PERL, and VISUAL STUDIO PATHS
REM Base Variables
SET _BLD_NASM=c:\nasm\bin
SET _BLD_PERL=c:\perl64\bin
SET _BLD_VSTUDIO=c:\vstudio
REM ######################################
Echo Initializing the Visual Studio Build environment
call %_BLD_VSTUDIO%\VC\vcvarsall.bat x86
Echo adding Perl to Path
set PATH=%_BLD_PERL%;%PATH%
Echo Adding NASM to Path
set PATH=%_BLD_NASM%;%PATH%
echo #######################################
echo Build environment is ready
echo TO BUILD:
echo perl Configure VC-WIN32 (or perl Configure debug-VC-WIN32)
echo ms\do_nasm.bat
echo nmake -f ms\ntdll.mak (or nmake -f ms\nt.mak for a static lib)
echo #######################################
Then to build:
Open up a clean command shell window. Preferably your PATH environment is already "clean" and doesn't contain Visual Studio. Also your environment should not have any LIB or INCLUDE values set. (Type set at the command prompt. If you don't see an entry for LIB or INCLUDE yet that's good).
cd to the directory of your openssl sources. Copy the bldenv.cmd script above to this directory.
Run the script above (bldenv.cmd)
Then run: ms\do_nasm.bat
Followed by: nmake -f ms\ntdll.mak
That should do it.
I need to convert PDF files to text to extract information using Perl. But I am not getting the text file in positional format means the position of the elements in the PDF and text should be same. I tried CAM::PDF::PageText but the output is very different.
I have come across posts referring to pdftotext and Poppler but I am not able to setup any of these in my Windows 10 64-bit system.
Please let me know if there are any other ways to solve this problem.
What you really want is pdftohtml with the -xml output. You can build it on Windows.
There are 2 ways to compile poppler on Windows:
using mingw compiler under cygwin
using native Visual Studio (msvc) makefile
This document describes the second method.
...
You can download Visual Studio Community Edition subject to license terms to get the 2013 and 2015 versions of compilers and build tools along with the IDE.
Or, you can just get the Visual C++ build tools. See also Walkthrough: Compiling a Native C++ Program on the Command Line.
Sorry for the delay but finally I got a solution for this which is pdftotext by Xpdf and the best way is to download pre compiled binaries (.exe) files. And then using the commmand line invaocation we can use the various tools like pdftohtml, pdftotext etc.
Look at this page
http://www.foolabs.com/xpdf/download.html
and under the heading "Precompiled binaries" you can find that.
On command prompt you need to change directory to the place where the binary is present then call the binary with the file as parameter
Exapmle: pdftotext File1.pdf
The above command will give File1.txt in the same folder where the binary is present.
I have a python build script I'm using to build a number of projects that are configured via CMake on windows. Previously, we used MSVC to build these projects, and everything was fine. I want to try to incorporate ICC into the build now, via these python scripts. I can choose the native compiler directly in the UI if necessary, but I'd rather do everything programmatically.
Problem is, it's failing with either syntax errors, or just not paying attention to the cmake options.
I can set:
"CMAKE_CXX_COMPILER:PATH":"C:/Program Files (x86)/Intel/Composer XE 2013/bin/intel64/icl.exe",
"CMAKE_C_COMPILER:PATH":"C:/Program Files (x86)/Intel/Composer XE 2013/bin/intel64/icl.exe"
And that's part of a cmakeItems array that's then fed into the generation:
generate(x86Generator, cmakeItems, osName, buildTarget)
where the other options are set via command line switches (for x86generator and buildTarget) or by default (ie, osName is detected in the script itself).
Before trying anything, I'm running this from a command line prompt where I've run
iclvars intel64
in the icc bin directory to ensure that all of the icc variables are properly configured, and I can type icl on the command line and confirm that it's in the path.
Running the above means that the C compiler remains the default msvc compiler.
I've also tried running:
set(CMAKE_C_COMPILER_INIT icl)
set(CMAKE_CXX_COMPILER_INIT icl)
but that's giving me a syntax error on the icl portion. I thought that maybe it's a path issue, but doing:
set(CMAKE_C_COMPILER_INIT "C:\Program Files (x86)\Intel\Composer XE 2013\bin\intel64\icl")
set(CMAKE_CXX_COMPILER_INIT "C:\Program Files (x86)\Intel\Composer XE 2013\bin\intel64\icl")
is also giving me a syntax error.
So how can I programmatically set the C/CXX compiler from a python script calling cmake?
On the command line you specify the compiler via the environment variables CC and CXX. I'ld guess you need to properly prepare the envornment of the cmake command and you should not change CMakeLists.txt internals.
E.g.
import subprocess
subprocess.Popen('CC=%s CXX=%s cmake ../path/to/src' %('icc','icpc'))
The answer is:
ICC does not work with CMake on Windows, so don't bother.
http://www.cmake.org/Bug/view.php?id=6929
Much better to run it with some form of visual studio compiler and then mess about with icprojconverter:
http://software.intel.com/en-us/articles/ICProjConvert100
I'm rebuilding a flash loader utility for a TI chip and am facing a minor issue that's affecting my workflow. I'm using a 64-bit Win7 PC and rebuilding the utility using make on cygwin bash shell. make and cygwin version numbers below.
$ make -v
GNU Make 3.82.90
Built for i686-pc-cygwin
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ uname -a
CYGWIN_NT-6.1-WOW64 DEEDAA 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin
One step in the build process calls a previously generated utility (windows executable) to generate the bin file that is required for the TI processor.
../../AISUtils//HexAIS_OMAP-L138.exe -ini ../sft_hexais.ini -o ../sft_C6748_SPI_MEM.bin ../sft_C6748_SPI_MEM.out
After this command is called there is no progress seen on the cygwin command line. However, execution of the command does complete, generating the files specified in this step and proceeds with the steps that follow in the makefile. It's just that I can never regain control of this window. I always need to kill the window, start another instance of cygwin.
If I try to kill the cygwin window immediately I get the message below.
mintty
Processes are running in session
Close anyway?
If I wait a while (the time to complete the steps that follow), then I can kill the window without this message popping up.
The same command on the windows command line is executed without any stalls and I do regain my command line.
c:\ti\boot_tools\OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\GNU\AISUtils>HexAIS_OMAP-L138.exe -ini ..\sft\sft_hexais.ini
-o ..\sft\sft_C6748_SPI_MEM.bin ..\sft\sft_C6748_SPI_MEM.out
-----------------------------------------------------
TI AIS Hex File Generator for OMAP-L138
(C) 2012, Texas Instruments, Inc.
Ver. 1.27
-----------------------------------------------------
Begining the AIS file generation.
AIS file being generated for bootmode: UART.
Parsing the input object file, ..\sft\sft_C6748_SPI_MEM.out.
AIS file generation was successful.
Wrote 15464 bytes to file ..\sft\sft_C6748_SPI_MEM.bin.
Conversion is complete.
It seems to me that something about the way the command is constructed is pushing commands on to another shell or forcing it to run in the background. Any thoughts on what may be going on or steps I can try to debug the issue?
file format of the executable that stalls
$ file AISUtils/HexAIS_OMAP-L138.exe
AISUtils/HexAIS_OMAP-L138.exe: PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows
Link to TI wiki that explains the build process. The link provides general instructions on rebuilding the utility and is very unlikely to provide any specific information related to my question. I'm only including it in case someone needed more background about the tools or the process.
http://processors.wiki.ti.com/index.php/Rebuilding_the_Flash_and_Boot_Utils_Package
Thanks.
Running Windows console applications inside a Cygwin (MinTTY) terminal is usually a terrible idea.
Try running inside a Windows (cmd) console or using cygstart to launch in a new window (in a Makefile, -w would probably be useful too).