what the difference of command process from terminal input and from Makefile? - gcc

i'm newbie use MinGW64 and msys2.
i have write simple program, just output "hello,world", but it links a dll for test.
#include <stdio.h>
int main() {
printf("hello, world\n");
return 0;
}
i run command in terminal like this:
$ gcc -g -Wall -I/usr/local/include -L/usr/local/bin -llua53 --shared -o test.dll main.c
it's works well.
but i write a Makefile use same command like this:
all: main.c
gcc -g -Wall -I/usr/local/include -L/usr/local/bin -llua53 --shared -o test.dll main.c
the error was output:
$ mingw32-make.exe
gcc -g -Wall -I/usr/local/include -L/usr/local/bin -llua53 --shared -o test.dll main.c
E:/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -llua53
this problem confused me, what the difference of command process from terminal input and from Makefile?

mingw32-make.exe is for use with the windows command shell and doesn't understand POSIX paths, you need to use make.exe.

Related

mingw32-make only runs the first dependency line

My Makefile:
helloworldlib.obj: helloworldlib.cpp
g++ -Wall -o helloworldlib.obj -c helloworldlib.cpp
helloworld.obj: source.cpp
g++ -Wall -o helloworld.obj -c source.cpp
helloworld.exe: source.cpp helloworld.obj
g++ -Wall -o helloworld.exe helloworld.obj helloworldlib.obj
I'm not sure what's wrong with this, when I run mingw32-make it only executes the first g++ -Wall -o helloworldlib.obj -c helloworldlib.cpp.
As far as I know this makefile is syntactically correct, mingw just doesn't seem to be able to find the other lines.
This is how make works. If no target is provided on the command line (e.g. mingw32-make helloworld.exe), by default it builds the first target defined in the file. See for instance: https://stackoverflow.com/a/2057716/2249356.
As a quick fix, you can just move the rule for helloworld.exe to the top of the file and then make will build all.
And, I think that the last rule is supposed to read
helloworld.exe: helloworld.obj helloworldlib.obj
g++ -Wall -o helloworld.exe helloworld.obj helloworldlib.obj
rather then with the source.cpp and its object code helloworld.obj as dependencies.

MinGW compilation "file not recognized: File format not recognized"

I'm trying to compile a c++ program and I am having some issues. In particular, when I use x86_64-w64-mingw32-gcc as my compiler, it complains half way through my compilation saying "tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized".
Here is my makefile (not mine, I'm trying to adapt this makefile to a cygwin environment) https://pastebin.com/vgnVYJUL
Here is the console output when I run make:
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver.cpp.o src/libfastms/solver/solver.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_base.cpp.o src/libfastms/solver/solver_base.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_host.cpp.o src/libfastms/solver/solver_host.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/has_cuda.cpp.o src/libfastms/util/has_cuda.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/image_mat.cpp.o src/libfastms/util/image_mat.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
ld -r -o tmp/src/libfastms/libfastms.o tmp/src/libfastms/solver/solver.cpp.o tmp/src/libfastms/solver/solver_base.cpp.o tmp/src/libfastms/solver/solver_host.cpp.o tmp/src/libfastms/util/has_cuda.cpp.o tmp/src/libfastms/util/image_mat.cpp.o
tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized
Makefile:167: recipe for target 'tmp/src/libfastms/libfastms.o' failed
make: *** [tmp/src/libfastms/libfastms.o] Error 1
Some other notes:
I don't have this problem when I compile with g++ (only seems to be minGW)
A common solution to this problem is to clean the directory of residual object files. This does not work.
Another common reason for this is trying to compile .h files. Obviously I am not doing this.
Thanks in advance.
You are compiling your object files with a 64-bit compiler driver, w64-mingw32-gcc,
and with -m64 you are explicitly directing it to generate 64-bit code (unnecessarily,
as that is its default). But you are linking with a 32-bit linker that does not
understand 64-bit object files.
This is happening because in your makefile you are, unusually, invoking ld
explicitly for your incremental solver linkage:
COMMAND_LINK_SOLVER=ld -r -o $# $^
rather than delegating linkage to your compiler driver in the usual way, and
a 32-bit ld from a different toolchain is being found in your PATH before
the 64-bit one belonging to your mingw-w64 toolchain.
To avoid this, invoke the linker via the compiler driver as normal, which for your
solver linkage means:
COMMAND_LINK_SOLVER=$(GXX) -Wl,-r -o $# $^
You can depend on w64-mingw32-gcc to invoke the ld that was installed with it.
There is no need to correct your main linkage as it is already done the right way.

How to set gcc flags in Emscripten

I compile with the following command:
gcc -Wall -march=native -O3 -ffast-math -I/usr/local/include -I/usr/local/include -o waon main.o notes.o midi.o analyse.o fft.o hc.o snd.o -L/usr/local/lib -L/usr/local/lib -lfftw3 -L/usr/local/lib -lsndfile -lm
I now would like to compile with Emscripten. How do I convert the above gcc command into an emcc command?
The command you have described in the question is linking rather than compiling. However in general you should just be able to replace gcc with emcc and it will do the right thing. In this case you will need to replace not only this linking command but also the commands used to compile the sources to the .o files.
It would probably be a good idea to take out the -march option.
It looks like your project is using libsndfile and FFTW. You will probably need to compile these libraries yourself using emscripten. Both of them are using autotools so with a bit of luck you can compile them with emscripten simply by adding the following parameters when you run the configure script:
./configure --prefix=$HOME/emscripten-libs CC=emcc
make && make install
Then when you link your program you can specify -L$HOME/emscripten-libs/lib instead of -L/usr/local/lib.
Make research about emsdk download&setup on your computer.
Download emsdk instruction
Next interest link is :
emcc or em++ instruction
https://emscripten.org/docs/tools_reference/emcc.html
When you setup emcc in command line you can see this project (i make emcc final look based on python script runner.py etc.):
c-cpp-to-javascript
Basic and useful example's :
Pretty analog with gcc :
Args:
-lGL for openGL
-s TOTAL_MEMORY=512MB --memory-init-file 1 Memory staff
--preload-file folderWithImages/--use-preload-plugins If you use assets
-I forInclude/someheader.h
-L libraryFolder/someLib.lib
-std=c11
Simple run:
./emcc -O2 a.cpp -o a.js
or
./emcc -O2 a.cpp -o a.html
Links:
./emcc -O2 a.cpp -o a.bc
./emcc -O2 b.cpp -o b.bc
./emcc -O2 a.bc b.bc -o project.js
Or :
to get JS
emcc -s WASM=1 myAdds.a myLib.a source1.c source2.cpp -o build.js
to get html
emcc -s WASM=1 myAdds.a myLib.a source1.c source2.cpp -o build.html
Link together the bitcode files:
emcc project.bc libstuff.bc -o allproject.bc
Compile the combined bitcode to HTML
emcc allproject.bc -o final.html
Important note :
You can't take an existing .a library and convert it. You must build lib with emcc also.

How to compile FastCGI++ Code?

What command should I use to compile FastCGI++ Code?
The documented command gives me several errors.
user#user:~/code$ g++ -o main.fcgi main.cpp pkg-config –libs –cflags fastcgi++
g++: error: pkg-config: No such file or directory
g++: error: –libs: No such file or directory
g++: error: –cflags: No such file or directory
g++: error: fastcgi++: No such file or directory
Sometimes FastCGI++ is compiled with it's Boost libraries dynamically. This means, afaik, that you need to link to them as well when you compile your code.
g++ -o main.fcgi main.cpp -lfastcgipp -lboost_system -lboost_thread
You need backticks for you pkg-config command
g++ -o main.fcgi main.cpp `pkg-config --libs --cflags fastcgi++`
In my system, this command is interpreted as
g++ -o main.fcgi main.cpp -I/usr/local/include -pthread -L/usr/local/lib -lfastcgipp -lboost_thread-mt -lboost_system-mt -lboost_date_time-mt

cannot link boost regex into mingw

my mingw compiler: http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/32-bit/threads-posix/sjlj/x32-4.7.2-release-posix-sjlj-rev6.7z
boost: http://sourceforge.net/projects/boost/files/boost/1.52.0/boost_1_52_0.7z
(both on D: drive)
code:
#include <boost\regex.hpp>
int main() {
boost::regex reg("[a-z]+");
}
command line:
SET PATH=%PATH%;D:\mingw\bin;D:\mingw\include
g++ -I "d:\mingw\include" -I "d:\boost" -Os -s -o test.exe test.cpp -std=c++11 -static -L "D:\boost\stage\lib" -lboost_regex
In the d:\boost\stage\lib directory there is libboost_regex-mgw47-mt-1_52.a.
And the process returns :
d:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lboost_regex
collect2.exe: error: ld returned 1 exit status
If I put the exact name of the *.a file the result is cannot find -llibboost_regex-mgw47-mt-1_52.a
even whole path that is -ld:\boost\stage\lib\libboost_regex-mgw47-mt-1_52.a doesn't work. Whatever I put after the -l has the same effect.
As you can see here you must use either (-l followed by the named of the library removing the lib preffix and the extension .a):
g++ -I "d:\mingw\include" -I "d:\boost" -Os -s -o test.exe test.cpp -std=c++11 -static -L "D:\boost\stage\lib" -lboost_regex-mgw47-mt-1_52
or (full path of the library without using -l):
g++ -I "d:\mingw\include" -I "d:\boost" -Os -s -o test.exe test.cpp -std=c++11 -static D:/boost/stage/lib/libboost_regex-mgw47-mt-1_52.a
PS:One thing I personally do is build boost using --layout=tagged. This makes the name of the libraries a lot more manageable (in this case libboost_regex-mt.a).

Resources