Here is the case where I run link.exe on libraries to create an executable; but the executable does not work.
file1.cpp is compiled to file1.obj;
file2.cpp is compiled to file2.obj;
file3.cpp is compiled to file3.obj which includes the function of main;
file1.obj is lib-ed into file1.lib;
file2.obj is lib-ed into file2.lib;
file3.obj is lib-ed into file3.lib;
Here is the command line used to link file1.lib, file2.lib and file3.lib into test.exe:
"link.exe file3.lib file2.lib file1.lib /nologo /OUT:test.exe /ENTRY:mainCRTStartup /SUBSYSTEM:CONSOLE libcmt.lib"
when I run ./test.exe, it returns 1 which means it crashed somewhere;
while when I run the following command line:
"link.exe file3.obj file2.lib file1.lib /nologo /OUT:test.exe /ENTRY:mainCRTStartup /SUBSYSTEM:CONSOLE libcmt.lib"
everything is fine and ./test.exe runs well.
May I ask your help to let me know the difference btw the above two commend lines internally?
Thanks.
Damon
You are probably running different code because your .obj modules aren't used.
Check your map file. The .obj modules from a library are copied only if there is at least on external that it resolves. .obj files specified at the command line are always linked.
Related
In the build I'm trying to do, there're 2 steps to generate the output
a.bin -> a.c (convert any file into a C file with an array storing the contents)
a.c -> a.o
a.c could be massive and should be deleted after a.o is generated.
Here's what I tried so far
Use separate builders for each step. For the last step, use target.AddPostAction(Delete("a.c"))
This does delete the temp file, but when you build again, a.c gets regenerated because SCons builds all targets by default unlike make
Is there some command to tell SCons to not build a target unless it's needed by another target? It would be the opposite of AlwaysBuild()
Create a custom builder that does both steps (target=a.o, source=a.json), so that SCons doesn't even know about a.c.
This required me to generate my own command for compiling C, which works for GCC, but not the Microsoft compiler. Is there any way to get the SCons generated C compile command or have SCons execute that command immediately?
Did you try:
Ignore('a.o','a.c')
haven't tried, but it might work.
I have used CMake to make a library and then made a test exe. After building, I would like to automatically run my test cases. Here is my CMakeLists.txt. It makes the .exe OK but does not run it. I am using Linux.
cmake_minimum_required (VERSION 2.8.7)
project (tests)
set(LIBRARY_NAME exetests)
set(LIBRARY_SOURCES RunAllTests.cpp Tests.cpp )
set(CMAKE_CXX_FLAGS "-fPIC -Werror -O2 -std=c++0x -g")
add_executable(exetests ${LIBRARY_SOURCES})
target_link_libraries(exetests CppUTest )
target_link_libraries(exetests CppUTestExt )
target_link_libraries(exetests testLibrary )
#THIS IS WRONG. EXE is not Run
add_custom_target( COMMAND ./exetests )
You can use CTest for testing of executables created by CMake. In your CMakeLists.txt, use commands enable_testing and add_test
...
enable_testing()
...
add_executable(exetests ${LIBRARY_SOURCES})
...
add_test(NAME mytest1 COMMAND exetests)
in your binary directory, compile make exetests and run testing by ctest. Some additional information could be found on CMake Wiki.
From the documentation:
The second signature adds a custom command to a target such as a library or executable. This is useful for performing an operation before or after building the target. The command becomes part of the target and will only execute when the target itself is built. If the target is already built, the command will not execute.
add_executable(RunAllTests RunAllTests.cpp)
target_link_libraries(RunAllTests imp_cpputest LedDriverTest LedDriver sprintfTest RuntimeErrorStub)
add_custom_command( TARGET RunAllTests COMMAND cd ../bin && ./RunAllTests POST_BUILD)
I downloaded a source code from codeproject.com
In the zip file only .cpp files and .hpp files were present but no .dsw (vc++ work space) file.
how to compile the files in vc++.
source code link: http://www.codeproject.com/Articles/13852/BasicExcel-A-Class-to-Read-and-Write-to-Microsoft
As far as I know, vc++ requires a dsw. That said, you can easily create one by creating a project + workspace and add import all the files into the project.
Unless the code requires special compile options (unlikely if it comes without a project file), this should work fine.
When you compile in VisualC++ cl.exe is executed in order to compile a s program.
So a way to compile that does not require dsw file might be running compilation in command line. This is an example for a source file main.cpp:
call vsvars32.bat && cl /MD /Od /EHsc /GR /Zi /Oy- main.cpp
On my computer the full path to vsvars32.bat is
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat
dsw is an ancient format, and is replaced by .sln and .vcxproj files. What I would suggest would be File -> New -> Project from existing code, browse to the directory with the cpp/hpp files and let Visual Studio create the project with default compiler switches - so you won't have to run cl.exe from the command line as suggested here.
That being said, the chances of circa-2006 c++ code to work on IDEs 4 versions later are small. You will almost certainly have to understand and fix the code - or find a more recent one that does what you need.
I have a CMake module to locate FreeGLUT:
FIND_PATH(FREEGLUT_INCLUDE_DIR NAMES GL/freeglut.h)
FIND_LIBRARY(FREEGLUT_LIBRARY NAMES freeglut freeglut_static)
SET(FREEGLUT_LIBRARIES ${FREEGLUT_LIBRARY})
SET(FREEGLUT_INCLUDE_DIRS ${FREEGLUT_INCLUDE_DIR})
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(FreeGLUT DEFAULT_MSG FREEGLUT_LIBRARY FREEGLUT_INCLUDE_DIR)
MARK_AS_ADVANCED(FREEGLUT_INCLUDE_DIR FREEGLUT_LIBRARY)
It works fine and locates freeglut_static.lib when I generate NMake Makefiles on Windows. I'm attempting to statically link FreeGLUT into my DLL:
FIND_PACKAGE(FreeGLUT REQUIRED)
ADD_LIBRARY(vti SHARED ${VTI_SOURCES})
ADD_DEFINITIONS("-DBUILD_VTI=1 -DFREEGLUT_STATIC=1")
INCLUDE_DIRECTORIES(${CMAKE_SOURCE_DIR}/include ${FREEGLUT_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES(vti ${FREEGLUT_LIBRARIES})
My source code builds correctly, but when it gets to the linking stage, VC++ fails with:
LINK : fatal error LNK1104: cannot open file 'freeglut.lib'
Which is strange since freeglut.lib isn't mentioned anywhere that I can see in the generated NMake makefiles. It should be trying to link with freeglut_static.lib, which CMake locates and sets in FREEGLUT_LIBRARIES.
What might be causing this?
This is caused with pragma directives in FreeGLUT code (see freeglut_std.h). Using FREEGLUT_STATIC should really fix that for you, but I think you should pass it to CMake without quotes: ADD_DEFINITIONS(-DBUILD_VTI -DFREEGLUT_STATIC)
I am trying to get PhysX working using Ubuntu.
First, I downloaded the SDK here:
http://developer.download.nvidia.com/PhysX/2.8.1/PhysX_2.8.1_SDK_CoreLinux_deb.tar.gz
Next, I extracted the files and installed each package with:
dpkg -i filename.deb
This gives me the following files located in /usr/lib/PhysX/v2.8.1:
libNxCharacter.so
libNxCooking.so
libPhysXCore.so
libNxCharacter.so.1
libNxCooking.so.1
libPhysXCore.so.1
Next, I created symbolic links to /usr/lib:
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCharacter.so.1 /usr/lib/libNxCharacter.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCooking.so.1 /usr/lib/libNxCooking.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libPhysXCore.so.1 /usr/lib/libPhysXCore.so.1
Now, using Eclipse, I have specified the following libraries (-l):
libNxCharacter.so.1
libNxCooking.so.1
libPhysXCore.so.1
And the following search paths just in case (-L):
/usr/lib/PhysX/v2.8.1
/usr/lib
Also, as Gerald Kaszuba suggested, I added the following include paths (-I):
/usr/lib/PhysX/v2.8.1
/usr/lib
Then, I attempted to compile the following code:
#include "NxPhysics.h"
NxPhysicsSDK* gPhysicsSDK = NULL;
NxScene* gScene = NULL;
NxVec3 gDefaultGravity(0,-9.8,0);
void InitNx()
{
gPhysicsSDK = NxCreatePhysicsSDK(NX_PHYSICS_SDK_VERSION);
if (!gPhysicsSDK)
{
std::cout<<"Error"<<std::endl;
return;
}
NxSceneDesc sceneDesc;
sceneDesc.gravity = gDefaultGravity;
gScene = gPhysicsSDK->createScene(sceneDesc);
}
int main(int arc, char** argv)
{
InitNx();
return 0;
}
The first error I get is:
NxPhysics.h: No such file or directory
Which tells me that the project is obviously not linking properly. Can anyone tell me what I have done wrong, or what else I need to do to get my project to compile? I am using the GCC C++ Compiler. Thanks in advance!
It looks like you're confusing header files with library files. NxPhysics.h is a source code header file. Header files are needed when compiling source code (not when linking). It's probably located in a place like /usr/include or /usr/include/PhysX/v2.8.1, or similar. Find the real location of this file and make sure you use the -I option to tell the compiler where it is, as Gerald Kaszuba suggests.
The libraries are needed when linking the compiled object files (and not when compiling). You'll need to deal with this later with the -L and -l options.
Note: depending on how you invoke gcc, you can have it do compiling and then linking with a single invocation, but behind the scenes it still does a compile step then a link step.
EDIT: Extra explanation added...
When building a binary using a C/C++ compiler, the compiler reads the source code (.c or .cpp files). While reading it, there are frequently #include statements that are used to read .h files. The #include statements give the names of files that must be loaded. Those exact files must exist in the include path. In your case, a file with the exact name "NxPhysics.h" must be found somewhere in the include path. Typically, /usr/include is in the path by default, and so is the current directory. If the headers are somewhere else such as a subdirectory of /usr/include, then you always need to explicitly tell the compiler where to look using the -I command-line switches (or sometimes with environment variables or other system configuration methods).
A .h header file typically includes data structure declarations, inline function definitions, function and class declarations, and #define macros. When the compilation is done, a .o object file is created. The compiler does not know about .so or .a libraries and cannot use them in any way, other than to embed a little bit of helper information for the linker. Note that the compiler also embeds some "header" information in the object files. I put "header" in quotes because the information only roughly corresponds to what may or may not be found in the .h files. It includes a binary representation of all exported declarations. No macros are found there. I believe that inline functions are omitted as well (though I could be wrong there).
Once all of the .o files exist, it is time for another program to take over: the linker. The linker knows nothing of source code files or .h header files. It only cares about binary libraries and object files. You give it a collection of libraries and object files. In their "headers" they list what things (data types, functions, etc.) they define and what things they need someone else to define. The linker then matches up requests for definitions from one module with actual definitions for other modules. It checks to make sure there aren't multiple conflicting definitions, and if building an executable, it makes sure that all requests for definitions are fulfilled.
There are some notable caveats to the above description. First, it is possible to call gcc once and get it to do both compiling and linking, e.g.
gcc hello.c -o hello
will first compile hello.c to memory or to a temporary file, then it will link against the standard libraries and write out the hello executable. Even though it's only one call to gcc, both steps are still being performed sequentially, as a convenience to you. I'll skip describing some of the details of dynamic libraries for now.
If you're a Java programmer, then some of the above might be a little confusing. I believe that .net works like Java, so the following discussion should apply to C# and the other .net languages. Java is syntactically a much simpler language than C and C++. It lacks macros and it lacks true templates (generics are a very weak form of templates). Because of this, Java skips the need for separate declaration (.h) and definition (.c) files. It is also able to embed all the relevant information in the object file (.class for Java). This makes it so that both the compiler and the linker can use the .class files directly.
The problem was indeed with my include paths. Here is the relevant command:
g++ -I/usr/include/PhysX/v2.8.1/SDKs/PhysXLoader/include -I/usr/include -I/usr/include/PhysX/v2.8.1/LowLevel/API/include -I/usr/include/PhysX/v2.8.1/LowLevel/hlcommon/include -I/usr/include/PhysX/v2.8.1/SDKs/Foundation/include -I/usr/include/PhysX/v2.8.1/SDKs/Cooking/include -I/usr/include/PhysX/v2.8.1/SDKs/NxCharacter/include -I/usr/include/PhysX/v2.8.1/SDKs/Physics/include -O0 -g3 -DNX_DISABLE_FLUIDS -DLINUX -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp"
Also, for the linker, only "PhysXLoader" was needed (same as Windows). Thus, I have:
g++ -o"PhysXSetupTest" ./main.o -lglut -lPhysXLoader
While installing I got the following error
*
dpkg: dependency problems prevent configuration of libphysx-dev-2.8.1:
libphysx-dev-2.8.1 depends on libphysx-2.8.1 (= 2.8.1-4); however:
Package libphysx-2.8.1 is not configured yet.
dpkg: error processing libphysx-dev-2.8.1 (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
*
So I reinstalled *libphysx-2.8.1_4_i386.deb*
sudo dpkg -i libphysx-2.8.1_4_i386.deb