RCK2 Resource Compiler - verifone

I'm new to VeriFone development. I need to compile the RCK file. I have used the below command to do that, but the command doesn't show any output or generate file. It does nothing.
C:\eVoAps\Tools>Rck2.exe -SC:\Bill\MyApp\Source\Resource\
MyApp -OC:\Bill\MyApp\Output\RV\Files\Resource\MyApp -M
Could anyone help me to fix this issue.

First of all, you say it does nothing. Does it at least give you an error? If so, what is it?
If it does NOTHING, then make sure you have the following files in your C:\eVoAps\Tools folder:
C1.DLL
CL.EXE
MSPDB60.DLL
If you are getting an error, then I suspect it is something close to this:
C:\Bill\MyApp\Source\Resource\MyApp.RCK(28) : fatal error C1034:
devman.h: no include path set Parse Error in
file[C:\Bill\MyApp\Source\Resource\MyApp.RI]! Invalid token [eof] at
line -1 offset -1 SSYacc0105e: Error token failed, no valid token
ERROR! Aborting compilation!
The reason I say that is because I'm pretty sure you need to include the VMAC includes and template for it to work. These can be found in %EVOVMAC%\include and %EVOVMAC%\template. To include, use the -J switch:
C:\eVoAps\Tools>Rck2.exe -SC:\Bill\MyApp\Source\Resource\MyApp
-OC:\Bill\MyApp\Output\RV\Files\Resource\MyApp
-M -J%EVOVMAC%\include -J%EVOVMAC%\Template
(Naturally, this will need to all be on 1 line, but I'm breaking it up here to make it more legible)
Note that if you are using nmake, you can have the resource file generated as part of the build. My make file does that with these lines:
$(ResDir)\$(ProjectName).res : $(ResDir)\$(ProjectName).rck
$(EVOTOOLS)rck2 -S$(ResDir)\$(ProjectName) -O$(ResDir)\$(ProjectName) -M
You may have noticed that I didn't use the -J switches here. That's because I've already included those paths in my project and that is captured in my build. I believe an alternative to either of these would be
$(ResDir)\$(ProjectName).res : $(ResDir)\$(ProjectName).rck
SET INCLUDE=$(INCLUDE);$(EVOVMAC)\include;$(EVOVMAC)\template
$(EVOTOOLS)rck2 -S$(ResDir)\$(ProjectName) -O$(ResDir)\$(ProjectName) -M
although that depends on how your build is set up.

Related

cannot get c program to build, compiler doesn't find include files

When attempting to compile a c program it never finds the include files. In a program located in ~/hbc/channel (offending file is in ~/hbc/channel/channelapp/source/xml.c) I get the following error:
source/xml.c:8:18: fatal error: mxml.h: No such file or directory
my PATH is set as follows:
dan#htpc~/hbc/channel-$ export | grep DEVKIT
declare -x DEVKITARM="/home/dan/devkitpro/devkitARM"
declare -x DEVKITPPC="/home/dan/devkitpro/devkitPPC"
declare -x DEVKITPRO="/home/dan/devkitpro"
And the file is there with the include files in the devkit:
dan#htpc~/hbc/channel-$ find ~/ | grep mxml.h
/home/dan/devkitpro/devkitPPC/include/mxml.h
Since it would be insane to have to edit every single file to point to its required library or header, I really need to ask.
Is there something I'm missing out? How can I set these paths properly so that the compiler sees them? I couldn't find anything else regarding this question and the development environment is set correctly since I could compile simpler code. It's this code requiring external libraries that's failing to find them.
Thanks in advance.

CMake: how to break a PRE_LINK infinite loop?

I'm trying to automatically label my application sign-on line with a build number. This application is a plain vanilla C one without graphic UI; it is intended for command line, therefore it is a "simple" one.
The sign-on id is located in a "template" source file which is customized by CMake with a configure_file() command. Recently, I fancied to include a build number in this sign-on id. Consequently, the customization can no longer be statically done at CMake time, but everytime make is invoked.
To achieve that, there are two possibilities in CMake:
add_custom_target(), but it is triggered even when nothing else changes in the source tree which does not reflect the state of the tree;
add_custom_command(), which can be triggered only when the application (target) needs to be linked again.
I opted for the second solution and did not succeed.
Here is an extract of my CMakeLists.txt, the sign-on id being in file ErrAux.c (template in PROJECT_SOURCE_DIR, configured in PROJECT_BINARY_DIR):
add_executable(anathem ... ${PROJECT_BINARY_DIR}/ErrAux.c ...)
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
This launches script BuildNumber.cmake just before the link step. It computes the next build number and customizes ErrAux.c with configure_file().
It works fine, except ...
It happens late in the make sequence and the update to ErrAux.c goes unnoticed. The sign-on id in the executable contains the previous build number.
Next time I run make, make notices the generated ErrAux.c is younger than its object module and causes it to be compiled again, which in turn causes a link which triggers a build number update. This happens even if no other file has changed and this loop can't be broken. This is clearly shown in the compiling log:
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-45
[ 36%] Built target anathem
The crux seems to be that add_custom_command(TARGET ...) can't specify an output file like add_custom_command(OUTPUT ...) does. But this latter form can't be triggered in PRE_LINK mode.
As a workaround, I forced a compilation to "refresh" the object module with:
add_custom_command(TARGET anathem PRE_LINK
COMMAND "${CMAKE_COMMAND}" "-DVERS=${PROJECT_VERSION}"
"-DSRC=${PROJECT_SOURCE_DIR}"
"-DDST=${PROJECT_BINARY_DIR}"
-P "${CMAKE_HOME_DIRECTORY}/BuildNumber.cmake"
COMMAND echo "Numbering"
COMMAND echo "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
COMMAND "${CMAKE_C_COMPILER}" "\$(C_DEFINES)" "\$(C_INCLUDES)" "\$(C_FLAGS)" -c "${PROJECT_BINARY_DIR}/ErrAux.c"
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
COMMENT "Numbering build"
VERBATIM
)
An explicit compilation is forced after sign-on id customization. It mimics what is found in the various Makefile's and my not be safe for production. It's a cheat trick on both CMake and make.
UPDATE: Option -c is required to postpone link step until the final application liniking process.
This addition creates havoc in the link, as shown by the log, where you see a double compilation (the standard make one and the add_custom_command() one):
Scanning dependencies of target anathem
[ 13%] Building C object AnaThem/CMakeFiles/anathem.dir/ErrAux.c.o
[ 14%] Linking C executable anathem
Numbering build
3.0.0-47
Numbering
/usr/bin/cc -DANA_DEBUG=1 -I/home/prog/projects/AnaLLysis/build/AnaThem -I/home/prog/projects/AnaLLysis/AnaThem -g /home/prog/projects/AnaLLysis/build/AnaThem/ErrAux.c
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
AnaThem/CMakeFiles/anathem.dir/build.make:798: recipe for target 'AnaThem/anathem' failed
make[2]: *** [AnaThem/anathem] Error 1
If I force a full recompilation, to make sure all sources are compiled, *main.c* included, I get the same error on `main`.
The only logical explanation is my manual C invocation is faulty and somehow destroys vital information. I checked with *readelf* that `main` is still in the symbol table for *main.c.o* and that it is still taken into account by the link step (from file *link.txt*).
UPDATE: Even with the correct link, I'm still experiencing the infinite loop syndrom. The generated application still has its sign-on id lagging behind the actual build counter.
Can someone give me a clue for the right direction?
FYI I'm quite new to CMake, so I may do things really wrong. Don't hesitate to criticize my mistakes.
The key to the solution is to put the generated module where make expects to find it. CMake organizes the build tree in a non-trivial way.
The shortcomming in my added compilation in add_custom_command() was to believe that by default the binary will be stored in the "usual" CMake locations. Since I forge manually my compiler command, this is not the case.
I found the module in the source directory, which is a consequence of the WORKING_DIRECTORY option, with name ErrAux.o and not ErrAux.c.o.
To obtain the correct behavior, I force an output location with:
-o "${PROJECT_BINARY_DIR}/CMakeFiles/anathem.dir/ErrAux.c.o"
Now, when I run make again, nothing happens since nothing changed.
Side question
To make the solution portable (if needed), are there CMake variables for CMakeFiles and anathem.dir directories? Or in the latter case, for the current target as "anathem" as the target name in add_custom_command()?

Autotools suite misplaces "man" file leading to installation failure

In a software I have to tweak, the man file is located under doc/ along with a simple Makefile.am file:
man_MANS = software.1
EXTRA_DIST = $(man_MANS)
Upon installation, I expect make install to copy the manual under /usr/local/share/man/, but the script - instead - will try to install the man under /usr/local/share/man/man1 - which does not exist - throwing an error and stopping the process.
I would expect a similar behavior if I assigned software.1 to man1_MANS, though.
What is going on ? How is this possible that automake does not create non-existing folders ?
man_MANS will try to figure out in which section to put the manual depending on the extension you gave it, so it is correct in this case that it would install into ${mandir}/man1.
Since you say that MKDIR_P is empty in your output, try to ensure that AC_PROG_MKDIR_P is being called in your configure.ac (it should be automatically called by AM_INIT_AUTOMAKE but since you said it's old it might have some issues).

How to stop make (in makefile) after "No such file or directory" error?

So, most of the times I'm testing if every include is correct on a given C/C++ code, I have a makefile with a gcc/g++ call with proper -I option for searching headers on specific directories (like every program) when I'm compiling sources to headers.
However, if the included directory is not correct and an undefined header appears (e.g. foo.h has #include and was not found), the gcc/g++ will just spit a bunch of errors for every include I have of that foo.h header for all other sources I'm compiling afterwards (and I'm already using -Werror -Wfatal-errors to make gcc/g++ to stop).
So, my question is simple: how can I tell makefile stop after the first error of the type "No such file or directory" it finds? It is really annoying it continue to compile sources and sources, giving me hundreds of errors just for a repeated error I already understood.
It probably continues because you told it to. See the following two options of GNU make:
-k, --keep-going Keep going when some targets can't be made.
-S, --no-keep-going, --stop
Turns off -k.
Put the header files into a variable and use that variable as a dependency. The following snippet will not build anything until the specified headers exist.
HEADERS=test.h other.h /usr/include/special.h
all: $(HEADERS) $(BINPROGS)
[... all other rules go here as usual ...]
*.h:
echo found $#
The ".h:" simply prints out each header that is found before any building even starts. The makefile itself stops if a header cannot be found (and it will stop before trying to compile anything).
I believe that that is what you wanted?
you can write a shell script to check for error conditions before running the make script.

Disabling vim's location list on missing C header file

Vim is pretty smart when it comes to C, so if one inserts a bogus header file such as #include <stdioo.h>, it complains by bringing up a location list with the following error:
foo.c:1|20| fatal error: stdioo.h: No such file or directory
|| compilation terminated.
Which is great, but for whatever reason, I get the same error when including the <mpi.h> header file. I know this is a vim problem b/c I can compile and execute the program with mpicc and mpiexec, respectively. Besides it being extremely irritating having it pop up every time I save the file, all syntax errors are ignored when this happens.
Is there any way to instruct vim to ignore this header file, or at least all the header files?
WHERE on your filesystem is the <mpi.h> file located?
Often it's one level down, such as /usr/include/mpi/mpi.h and would require <mpi/mpi.h> to access it.
You may need to add another directory path to the -I option list of your compiler, or add the directory path to VIM's path option variable
:help 'path
Will get you started on the VIM side, you'll need to look up how to add options to your current setup, no idea if you're using cmake, make, visual something, netclipse or whatever.
But a simple 'locate mpi.h' would be the place to start, since you know it's there.
You said "pop-up" ... are you using syntastic or such? Again, finding the proper path would help there too. Evidently mpicc knows the proper path to the include files, you just need to tell VIM. (via the 'path' option)

Resources