I'm using cygwin and gcc to create a new dll on Windows XP. I have an existing dll (MyCApi.dll) and example_wrap.o that I want to both use to create a new dll, example.dll. I ran the below gcc command and it looks like gcc can't find MyCApi.dll. I have the directory it lives in on my path. Is there something else I need to do?
$ gcc -shared example_wrap.o -mno-cygwin -Wl,--add-stdcall-alias -lMyCApi -o example.dll
/usr/bin/ld: cannot find -lMyCApi
collect2: ld returned 1 exit status
I'm not sure what you mean when you say it's on your path (LIBRARY_PATH?) but I suspect if you add
-L/directory/where/dll/lives
to the compilation line it'll work just fine.
Related
I am trying to create a program using the libusb-1.0 library
After I installed the library when I try to compile like so
gcc -g main.c -o test.exe -lusb-1.0
i get the following error
gcc.exe: error: .0: No such file or directory
what do I have to type for the linkage option "-lusb-1.0" to be read properly
I am using mingw64 on Windows
This can be solved by adding single or double quotes around '-lusb-1.0'
for example here is the code i used to compile
gcc *.c -o test.exe '-lusb-1.0'
I was trying to build zlib with CMake 3.9.0, output set to MinGW Makefiles, and noticed upon trying to call mingw32-make in the output dir that there was a weird error message which very much looks like a quoting error to me.
D:\zlib-1.2-11> mingw32-make
[ 2%] Generating zlib1rc.obj
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files\mingw-w64\x86_64-7.1.0-win32-seh-rt_v5-rev0\mingw64\bin\windres.exe: preprocessing failed.
CMakeFiles\zlib.dir\build.make:60: recipe for target 'zlib1rc.obj' failed
mingw32-make[2]: *** [zlib1rc.obj] Error 1
CMakeFiles\Makefile2:103: recipe for target 'CMakeFiles/zlib.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/zlib.dir/all] Error 2
Makefile:139: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
What could be the cause of this error and how can I fix it? If it were only zlib, I could scrape the net for pre-built binaries, but this has happened with some other builds, too.
This appears to be a bug in MinGW's version of windres.exe, although I'm also going to heap some blame onto CMake for it's appalling method of invoking windres, which is what is causing this to fail.
The Problem
CMake understands that Windows Resource .rc files are a thing, and that they are compiled with the Windows Resource Compiler (aka windres.exe), which it wraps in the default variable CMAKE_RC_COMPILER.
The problem is, that rather than just invoking windres like a normal person, CMake thinks it's being clever by invoking it like so...
cmd.exe /C "cd /D C:\Users\username\zlib-1.2.11\build && "C:\Program Files\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev0\mingw64\bin\windres.exe" -D GCC_WINDRES -I C:/Users/username/zlib-1.2.11 -I C:/Users/username/zlib-1.2.11/build -o C:/Users/username/zlib-1.2.11/build/zlib1rc.obj -i C:/Users/username/zlib-1.2.11/win32/zlib1.rc"
Evidently it doesn't understand the notion of the current working directory, or the system path variable (which it used to find windres in the first place). If we were to simplify the command, it would look like this...
windres -D GCC_WINDRES -I.. -I. -ozlib1rc.obj -i ../win32/zlib1.rc
Those two commands carry the exact same meaning, except the second one actually works.
The Solution
We have to step in and stop CMake from trying to be clever.
cmake .. -DCMAKE_RC_COMPILER=windres
I have MSVC 2017 installed, and CMake assumes that I want to use that by default, despite none of its environment variables being set and it not being in the path (in normal usage, one must invoke the vcvars64.bat file before using MSVC, this behaviour predates CMake). So I have to use -G "MinGW Makefiles", except that I also have sh.exe in my path (because Git), and that just blows CMake's mind, so I need the command...
cmake .. -G"MSYS Makefiles" -DCMAKE_RC_COMPILER=windres
The CMake file author should have quoted strings containing unknown filesystem paths, i.e. variables and the VERBATIM option also avoids headaches:
if(MINGW)
# This gets us DLL resource information when compiling on MinGW.
if(NOT CMAKE_RC_COMPILER)
set(CMAKE_RC_COMPILER windres.exe)
endif()
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
COMMAND "${CMAKE_RC_COMPILER}"
-D GCC_WINDRES
-I "${CMAKE_CURRENT_SOURCE_DIR}"
-I "${CMAKE_CURRENT_BINARY_DIR}"
-o "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
-i "${CMAKE_CURRENT_SOURCE_DIR}/win32/zlib1.rc"
VERBATIM)
set(ZLIB_DLL_SRCS "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj")
endif(MINGW)
I have installed the cds library with command ./build.sh -b 64 -z '-std=c++0x' -l '-L /usr/lib/x86_64-linux-gnu' --with-boost /usr/include/boost --amd64-use-128bit at build folder.
After I tried to compile the example init.cpp of src folder, I typed this in terminal: g++ init.cpp -o init, and terminal showed: fatal error: cds/init.h: No such file or directory.
What should I do for compilation command in this case?
Thanks.
For general troubleshooting in cases like this, i would recommend finding where on the system the file got installed (if your build.sh actually installed the file). You would be able to find the missing header file using
find / -path '*/cds/init.h' 2>/dev/null
Then you need to supply two parameters to g++:
First one gets the compiler to know about the include files from the install directory
-I path_to_folder_one_step_above_cds_folder
Second one gets the linker to know about the librarys location. If the library file is called libcds.so, you can find it by running
find / -name libcds.so 2>/dev/null
So for linking, you supply the flag
-L path_to_folder_one_step_above_libcds.so
In your case you might not need the -L flag, since most of your library supposedly is header only.
UPDATE: the build.sh script is printing out important information at the top, starting with "Building with the following options:". The important bits will be "Compile options:" and "Link options:". Those should be enough to solve your specific option.
UPDATE2: build.sh also exports some flags which might include more options. You can print them out directly after running build.sh by running
echo LDFLAGS=$LDFLAGS
echo CFLAGS=$CFLAGS
echo CXXFLAGS=$CXXFLAGS
you are likely to need to pass all these options to g++ when compiling and linking against that library. LDFLAGS are specific to the linker only. Both the other ones are needed for compiling c++ files.
I can run compile in OSX terminal using g++ -Wall -c pa1.cpp -o pa1. Which creates pa1, so I know my compilation works in terminal but I am having issues with execution. I have tried ./pa1 , ./a.out, pa1 and few others. I believe the issue is with Xcode, yet the fact that my code will compile in terminal and creates an executable makes me unsure. Thought, I would ask here for suggestions before reinstalling Xcode.
Use g++ pa1.cpp -o pa1 and then you'll be able to run your new executable as ./pa1. This require that your whole program is in pa1.cpp. If it is spread in multiple files, you'll have to list all of them on the command-line.
As said in the comments, the -c option means compile, ie. Create an object file that can be passed to the linker to build an executable. If you don't use this option, g++ will first compile any source file, then invoke the linker on all the object files to create an executable named a.out by default (name comes from historical reason).
You can see that the output of your command was not an executable binary but an intermediate object file by using the file util.
i am using ubuntu 10.10
i am trying to compile simple helloworld file using
gcc -c option
the output file is created but it does not have execute permission
if i dont use -c option the output file has execute permission ..
Please help
The command gcc -c generates a non-executable object file. If you want the output to be executable, do not use the -c option.
I am not sure what you hoped -c was for, but it is exactly for not generating an executable, and your GCC is working as designed.
From the man gcc:
-c Compile or assemble the source files, but do not link. The linking
stage simply is not done. The ultimate output is in the form of an
object file for each source file.
It is not executable. It needs to undergo linking process to become an execution file.