So I'm on Windows, and I'm wondering how to build a DLL and a Static Library in MingW, and in different architectures like x86 and x64. I'm new to MingW, but not C++. I've been looking around Google a while and haven't found a way to do it yet, the reason being is because most of the tutorials I find are out-of-date.
GNU 'Make' File
Sources = Test.cpp Utilities.cpp
Objects = $(Sources:.cpp=.o)
ProjName = MyProgram
BuildName = $(ProjName).dll
$(ProjName) : $(Objects)
g++ -o $(BuildName) $(Objects)
$(Objects) :
g++ -c -D TEST_DYNAMIC $(Sources)
Clean :
rm $(Objects) $(BuildName)
Addition Information
Mingw Version: 4.8.1-4
Attempts
http://www.mingw.org/wiki/sampledll
-shared is an unrecognized command.
Okay so I figured out why it wasn't working. Those sites are not out-of-date, my MingW was, but my system was using Cygwin, which is what I don't want. So I changed my 'Path' variable to direct it to the correct Mingw.
Related
I'm exploring right now open source tools to test my QT GUI Applications. After some research I found the promising:
TUG: GUI Unit Testing library https://github.com/pedromateo/tug_qt_unit_testing_fw
Unfortunately, it is a Linux library, but I'm developing windows applications with MSVC.
But I didn't gave up and installed Cygwin. My idea was to compile TUG with Cygwin and afterwards using it together with the cygwin1.dll in my testing framework.
TUG is being compiled using qmake Project files producing normal make files.
The first step was to include the switch -D__MINGW32__ in the DEFINES section of my qmake project file. This eliminates some compilation errors.
Then I ran my qmake with:
/cygdrive/[My Windows QMake Install Path]/qmake.exe –spec cygwin-g++ tug_base_lib
Then I ran make and it compiles fine, but failed in the last step linking the object files to the libTUG.dll. It ended up with a lot of undefined references errors.
My idea is, that make tries to link MSVC Windows Libraries to my libTUG.dll resulting in an error.
Does anyone has experience in using TUG together with Windows Applications?
The corresponding section in the generated Makefile, where the linking failed was probably:
$(TARGET): $(OBJECTS) $(SUBLIBS) $(OBJCOMP)
-$(DEL_FILE) $(TARGET) $(TARGET0) $(TARGET1) $(TARGET2)
$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(LIBS) $(OBJCOMP)
-$(QMAKE) -install ln -s $(TARGET) $(TARGET0)
-$(QMAKE) -install ln -s $(TARGET) $(TARGET1)
-$(QMAKE) -install ln -s $(TARGET) $(TARGET2)
where the Options where
LINK = g++
LFLAGS = -shared -Wl,-soname,libTUG.dll.1
LIBS = $(SUBLIBS) -L/usr/X11R6/lib -L[Path of my Windows QT Libs] -lQt5Widgets_vc14-x64 -lQt5Gui_vc14-x64 -lQt5XmlPatterns_vc14-x64 -lQt5Network_vc14-x64 -lQt5Test_vc14-x64 -lQt5Core_vc14-x64 -lGL -lpthread
TARGET = libTUG.dll.1.0.0
TARGETA = libTUG.a
TARGET0 = libTUG.dll
TARGETD = libTUG.dll.1.0.0
TARGET1 = libTUG.dll.1
TARGET2 = libTUG.dll.1.0
I'm trying to compile C++ project with gcc-make command but program giving this error. I already compiled Crypto++ and added include and lib folder but I dont know how to add this dir to gcc.
What should I do for fixing this "-lcrytopp" error?
I'm using makefile and this is line of 33-34.
$(TARGET): build $(OBJECTS)
$(CC) $(OBJECTS) -o $(TARGET) -lcryptopp
Error:
D:\Osman\CnC RA2\Mix\ccmix-crypto\ccmix-crypto>make
g++ src/mix_db_gamedb.o src/mix_db_gmd.o src/mix_header.o src/mix_db_lmd.o
src/mixid.o src/ccmix.o src/mix_file.o -o build/ccmix -lcryptopp
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../../mingw32
/bin/ld.exe: cannot find -lcryptopp
collect2.exe: error: ld returned 1 exit status
Makefile:34: recipe for target 'build/ccmix' failed
make: *** [build/ccmix] Error 1
Crypto++ directory:
Compile error:
You haven't added the directory containing the library to your link line. It should be something like -Lxxx where xxx is the path to the directory containing the cryptopp library:
$(TARGET): build $(OBJECTS)
$(CC) $(OBJECTS) -o $(TARGET) -Lxxx -lcryptopp
(replace xxx with the directory containing the cryptopp library)
What should I do for fixing this "-lcrytopp" error?
When working from the Crypto++ build directory on Unix compatibles, the project does not use include and lib (as your picture shows). Everything is placed in the root directory (as your picture shows).
If you perform a make install, then the directories are setup, but it appears you did not install. I should also say that MinGW is not usually tested anymore because the project is abandoned, so I'm not sure where make install actually installs to on MinGW.
To fix the compile error, tweak your make recipe:
$(TARGET): build $(OBJECTS)
$(CXX) $(CXXFLAGS) -I. $(OBJECTS) ./libcryptopp.a -o $(TARGET)
The recipe above uses CXX (C++ compiler) rather than CC (C compiler); it uses CXXFLAGS (which should be something like -DNDEBUG -g2 -O2); it calls out the header path (-I.); and it links to the static library (./libcryptopp.a). Linking to the static library will avoid your next set of problems.
You can follow MadScientist's advice and use -LXXX and -lcryptopp. You might even add a runpath with -Wl,-rpath,D:\Osman\CnC RA2\Mix\ccmix-crypto\ccmix-crypto. But at the end of the day, using -L and -l causes a fair amount of trouble. Avoid the future problems by statically linking libcryptopp.a.
Also see GNUmakefile | Compiling and Linking on the Crypto++ wiki.
Your fist picture shows ipch and Win32 directories. That usually means you built the Crypto++ library with Visual Studio. Now you are building a program with GCC. You should not mix and match compilers like that. Nothing good will come of it.
I have just started with iotivity and have been reading the documentation. On this setup page, under the heading running the c++ samples, it tells how to run the examples, but before that I should build them first and it seems the page Build the C++ samples it refers to, is missing.
When I tried to build the examples in a normal way using g++, it gave some missing header errors, meaning that's not the right way or will take a lot of effort.
Do any one know how to build the examples packet with iotivity release?
Place the following makefile in the iotivity/resource/examples directory :
IDIR=-I../include -I./../csdk/stack/include/ -I./../c_common/ -I./../oc_logger/include
CC=g++
CFLAGS=-Wall -std=c++11 $(IDIR) -loc -loctbstack -loc_logger -lpthread
SERV_OBJ = simpleserver.o
CLIENT_OBJ = simpleclient.o
%.o: %.cpp
$(CC) -c -o $# $^ $(CFLAGS)
#Build the simpleserver executable
all:simpleserver simpleclient
simpleserver:$(SERV_OBJ)
$(CC) -o $# $^ $(CFLAGS)
#Build the simpleclient executable
simpleclient:$(CLIENT_OBJ)
$(CC) -o $# $^ $(CFLAGS)
and then hit make on the terminal. Then execute simpleclient and simpleserver on two different terminals. In case you get the error :
./simpleclient: error while loading shared libraries: liboc.so: cannot open shared object file: No such file or directory
type the following:
export LD_LIBRARY_PATH=../../out/linux/x86_64/release
I researched a lot to find where the executables get generated for the c++ samples, finally found the path.
On 64-bit Ubuntu 14.04 LTS ,
when iotivity is built as follows:
$ scons
the executables get created in path /iotivity/out/linux/x86_64/release/resource/examples for the code present in /iotivity/resource/examples so you can just go to /iotivity/out/linux/x86_64/release/resource/examples and execute simpleserver(./simpleserver) and simpleclient(./simpleclient)
Check this page about IoTivity supported (and unsupported) examples :
https://wiki.iotivity.org/examples#
cd ${project_dir}/out/${TARGET_OS}/${TARGET_ARCH}/${BUILD_MODE}/resource/examples/
killall simpleserver simpleclient # make sure none are running
./simpleserver 2>&1 | tee simpleserver.log.txt &
./simpleclient 2>&1 | tee simpleclient.log.txt
Some c++ examples are not working in 1.3.0 while 1.2.1 should be ok
But if you want to build other examples from outside the main tree, I made a dedicated project that use gnu make.
Hope this helps
I had been working on a project that uses different sources and codes from many authors (in physics) and I want to merge them together and communicate between them.
The problem is that some of those sources and makefiles call first the linked libraries and then the c files:
$(CC) $(lflags) -o smith2demo smith2demo.o smith2.o
Until now on my institute's computer and in some other systems everything was working fine. There I have this gcc compiler:
$gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
So, I had not noticed this problem until I tried to run my code on Ubuntu:
gcc (Ubuntu 4.9.3-5ubuntu1) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
In ubuntu I get things like:
smith2.c:(.text+0x29b): undefined reference to `sincos'
I am aware of the linked libraries specifications and the reason for this, answered here:
GCC C++ Linker errors: Undefined reference to 'vtable for XXX', Undefined reference to 'ClassName::ClassName()'
Why does the order in which libraries are linked sometimes cause errors in GCC?
Why am I getting a gcc "undefined reference" error trying to create shared objects?
So, I have two questions:
Why if both gcc's are of recent versions, I do not have this problem in the Debian system?
How can I do to distribute this code to other people, without me telling them to change all makefiles where the libraries are called before the C files?
In most of the cases within my project, I use an overall Makefile and then I just change to the source folder and perform $(MAKE) in there.
Is there a way to set the --no-as-needed in general as an option for everyone or a more intelligent way of doing this?
I have very little experience with makefiles.
In my personal life, I use my own Makefile. Here is the simpler version of it.
MAIN = main
HEADER_DEFINITIONS = fibo
CC = g++-4.9 -std=c++11
COMPILE = -c
EXE = $(MAIN)
OPTIMIZE = -Os
SHELL = /bin/bash
ARGS = 20
all: link
#echo "Executing..........."
#echo " > > > > > > OUTPUT < < < < < < "
#$(SHELL) -c './$(EXE) $(ARGS)'
link: compile
#echo -n "Linking............."
#$(SHELL) -c '$(CC) -o $(EXE) *.o'
compile: $(MAIN).cpp $(HEADER_DEFINITIONS).cpp
#echo -n "Compiling........."
#$(SHELL) -c '$(CC) $(OPTIMIZE) $(COMPILE) $^'
clean:
#echo "Cleaning............"
#$(SHELL) -c 'rm -f *~ *.o $(EXE)'
If you want to further modify and add certain linker flags, it is completely possible
Edit 2 My personal Makefile
#
# A simple makefile for managing build of project composed of C source files.
#
# It is likely that default C compiler is already gcc, but explicitly
# set, just to be sure
CC = gcc
# The CFLAGS variable sets compile flags for gcc:
# -g compile with debug information
# -Wall give verbose compiler warnings
# -O0 do not optimize generated code
# -std=c99 use the C99 standard language definition
# -m32 CS107 targets architecture IA32 (32-bit)
CFLAGS = -g -Wall -O0 -std=c99 -m32
# The LDFLAGS variable sets flags for linker
# -lm says to link in libm (the math library)
LDFLAGS = -lm
# In this section, you list the files that are part of the project.
# If you add/change names of source files, here is where you
# edit the Makefile.
SOURCES = demo.c vector.c map.c
OBJECTS = $(SOURCES:.c=.o)
TARGET = demo
# The first target defined in the makefile is the one
# used when make is invoked with no argument. Given the definitions
# above, this Makefile file will build the one named TARGET and
# assume that it depends on all the named OBJECTS files.
$(TARGET) : $(OBJECTS)
$(CC) $(CFLAGS) -o $# $^ $(LDFLAGS)
.PHONY: clean
clean:
#rm -f $(TARGET) $(OBJECTS) core
I have a project of multiple source and header files and I wrote my own Makefile by specifying the required external libraries and headers (the directory containing the OpenCV header files and the directory containing the OpenCV libraries).
When I start compiling the project, it is compiled without any errors. However when writing the code, Eclipse reports errors on some functions of OpenCV, as if it did not know these functions. Since I have listed all the required headers and libraries in the makefile (see below), why does this problem occur?
CXXFLAGS = -O3 -g -Wall -fmessage-length=0 -I./include -I/usr/local/include/opencv
LIBS = -L/usr/local/lib -lcv -lcvaux -lhighgui -lcxcore -limgproc
MAIN_PROG_OBJS = MainProgram.o src/Utilities.o src/ImageStream.o src/VideoStream.o
MAIN_PROG_TARGET = MainProgram
TEST_PROG_OBJS = TestProgram.o src/Utilities.o
TEST_PROG_TARGET = TestProgram
$(MAIN_PROG_TARGET): $(MAIN_PROG_OBJS)
$(CXX) -o $(MAIN_PROG_TARGET) $(MAIN_PROG_OBJS) $(LIBS)
$(TEST_PROG_TARGET): $(TEST_PROG_OBJS)
$(CXX) -o $(TEST_PROG_TARGET) $(TEST_PROG_OBJS) $(LIBS)
all: $(MAIN_PROG_TARGET) $(TEST_PROG_TARGET)
clean:
rm -f $(MAIN_PROG_OBJS) $(MAIN_PROG_TARGET) $(TEST_PROG_OBJS) $(TEST_PROG_TARGET)
Eclipse tries to find the errors quickly, but does not update all the time. Do not rely only on the error messages of Eclipse.
For example if you have just added a file to your project, Eclipse might still be telling you that it could not find the file while in fact it is there.
Use Project -> Clean to update the error checking of Eclipse.