It seems for me that mingw wersion of gcc ignores CFLAGS environment variable. Am i right? How it could be fixed?
I've done following:
create simple test.c file
int main(int argc, char** argv) {
int a;
return 0;
}
and run form mingw bash prompt
$ export CFLAGS="-Wall"
$ gcc test.c <-- no warnings
$ gcc test.c -Wall
$ ... warning: unused variable 'a'
CFLAGS it's not an environment variable required or used by the gcc suite, you can find more about gcc and environment variables here.
Yeah, sorry, it seems makefile option
Related
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.
I am using gcc 4.9.2 with ccache 3.1.10. My shell environment contains GCC_COLORS=auto (from here; tried yes and always too).
As a minimal test I compile this main.c file
int main() {
int a;
return 0;
}
with gcc -c main.c -Wall -o main.o and observe (as desired)
main.c: In function ‘main’:
main.c:2:7: warning: unused variable ‘a’ [-Wunused-variable]
int a;
^
with main.c: and main.c:2:7:, ‘main’: and ‘a’ in bold face, the ^ in boldface green, and the warning: in magenta bold face.
Compiling with ccache the colorisation disappears.
NB: ccache gcc -Wall -c main.c -o main.o is colorless, but ccache gcc -Wall main.c -o main remains colored.
NB2: ccache gcc -Wall -c main.c -o main.o -fdiagnostics-color also preserves colors in the output.
Question: Is there a recommended way to have the export GCC_COLORS functionality with ccache? I'd prefer to have colors globally enabled (as through the ~/.MYSHELLrc) and without adding -fdiagnostics-color globally to $CFLAGS[0] and I want to avoid custom wrappers which parse the output messages (and might get confused with LC_MESSAGES settings).
[0]: I have many Makefiles which don't add their config to CFLAGS but overwrite the environment settings.
Not really sure it's relevant anymore, but I just tested with GCC_COLORS=yes with ccache version 3.4.1 and gcc 7.4.0 and that seems to work fine for me. I had the same issue when GCC_COLORS wasn't set.
I have a library: libfoo.dylib. The problem is illustrated in the commands:
$ install_name_tool -id "#rpath/libfoo.dylib" libfoo.dylib
$ install_name_tool -add_rpath "#executable_path/" libfoo.dylib
$ gcc -o foo foo.c -lfoo
$ ./foo #<==== I want this to work
dyld: Library not loaded: #rpath/libfoo.dylib
Referenced from: ~/./foo
Reason: image not found
$ install_name_tool -add_rpath "#executable_path/" foo #<=== I dont want to have to specify here where to look for the library
$ ./foo
Hello World
How do I achieve the goal of not having to specify at executable compile where the library is?
I must confess that I'm a little confused as to what you're trying to achieve. The entire point of using the runpath search path is that the images loading the library define the search path to be used when loading the library. What you're asking for is for the library to define where the executable should find it. That can be accomplished without using the runpath search path by simply setting the install name of the dylib to the appropriate value. Based on your particular example, it sounds like you want to set the install name to something like #loader_path/libfoo.dylib. Consider the following, which is along the same lines of your sample:
$ cat a.c
int a(void)
{
return 1;
}
$ cc -install_name "#loader_path/liba.dylib" -dynamiclib -o liba.dylib a.c
$ cat main.c
#include <stdio.h>
extern int a(void);
int main(int argc, char **argv)
{
fprintf(stderr, "A: %d\n", a());
return 0;
}
$ cc -L. -la -o main main.c
$ ./main
A: 1
$
The library tells executables that link against it how to find it by setting its install name, and nothing special needs to be done when linking the executable to have it find the library at runtime.
The only thing you need is to tell the linker to add the rpath in your binary. Actually, you tell gcc to tell the linker in the following way:
$ gcc -o foo foo.c -lfoo -Wl,-rpath=/some/path
Now if you use objdump to see what's in there:
$ objdump -x ./foo | less
You will see under Dynamic Section somthing like RPATH /some/path.
If having to type the same -Wl,-rpath=... is too cumbersome, ld accepts the #file option (I don't know about dyld but I suppose it does too):
$ echo "-rpath=/some/path" > ./ld-options
$ gcc ./foo.c -o foo -Wl,#ld-options
Other people have reported not being able to generate code coverage with XCode 4, but I find not only can I not do it from within XCode 4, I can't do it even with a simple toy program from the command line. I followed the examples given here and here, which led me to create this cov.c file:
#include <stdio.h>
int main (void) {
int i;
for (i = 1; i < 10; i++) {
if (i % 3 == 0)
printf("%d is divisible by 3\n", i);
if (i % 11 == 0)
printf("%d is divisible by 11\n", i);
}
return 0;
}
I then used the following commands in an attempt to generate code coverage:
g++ -c -g -O0 --coverage -o $PWD/obj/cov.o $PWD/cov.c
g++ -g -O0 --coverage -o $PWD/bin/cov $PWD/obj/*.o
$PWD/bin/cov
Alas, no cov.gcno file exists in the obj directory. In fact, the only files I have after this are:
cov.c
obj/cov.o
bin/cov
Furthermore, if I type nm bin/cov, I get the following:
0000000100001048 S _NXArgc
0000000100001050 S _NXArgv
0000000100001060 S ___progname
0000000100000000 A __mh_execute_header
0000000100001058 S _environ
U _exit
0000000100000e40 T _main
U _printf
0000000100001000 s _pvars
U dyld_stub_binder
0000000100000e00 T start
This suggests that libgcov.a was never linked in. If I replace
g++ -g -O0 --coverage -o $PWD/bin/cov $PWD/obj/*.o
with:
g++ -g -O0 --coverage -o $PWD/bin/cov -lgcov $PWD/obj/*.o
I get the exact same results.
More information:
g++ --version yields: "i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1
(Based on Apple Inc. build 5658) (LLVM build 2336.1.00)"
I've also tried using gcc (which is llvm-gcc).
I was able to figure out an answer to this question using help from this answer. Basically, I changed my coverage commands to use clang instead of g++ (because the example file was pure C, I went with clang instead of clang++, which I've verified works just fine with C++ files). From there, I was able to use lcov to generate output similar to what I'm used to seeing from Java/cobertura.
On Lion g++ is an alias for llvm-g++, as you have discovered. To invoke "real" gcc, use gcc-4.2 or g++-4.2:
g++-4.2 -g -O0 --coverage -o $PWD/bin/cov $PWD/obj/*.o
I have a working setup, where all files are in the same directory (Desktop). The Terminal output is like so:
$ gcc -c mymath.c
$ ar r mymath.a mymath.o
ar: creating archive mymath.a
$ ranlib mymath.a
$ gcc test.c mymath.a -o test
$ ./test
Hello World!
3.14
1.77
10.20
The files:
mymath.c:
float mysqrt(float n) {
return 10.2;
}
test.c:
#include <math.h>
#include <stdio.h>
#include "mymath.h"
main() {
printf("Hello World!\n");
float x = sqrt(M_PI);
printf("%3.2f\n", M_PI);
printf("%3.2f\n", sqrt(M_PI));
printf("%3.2f\n", mysqrt(M_PI));
return 0;
}
Now, I move the archive mymath.a into a subdirectory /temp. I haven't been able to get the linking to work:
$ gcc test.c mymath.a -o test -l/Users/telliott_admin/Desktop/temp/mymath.a
i686-apple-darwin10-gcc-4.2.1: mymath.a: No such file or directory
$ gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -lmymath
ld: library not found for -lmymath
collect2: ld returned 1 exit status
What am I missing? What resources would you recommend?
Update: Thanks for your help. All answers were basically correct. I blogged about it here.
$ gcc test.c /Users/telliott_admin/Desktop/temp/mymath.a -o test
edit: gcc only needs the full path to the library for static libraries. You use -L to give a path where gcc should search in conjunction with -l.
To include the math libraries, use -lm, not -lmath. Also, you need to use -L with the subdirectory to include the library when linking (-I just includes the header for compiling).
You can compile and link with:
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp /Users/telliott_admin/Desktop/temp/mymath.a
or with
gcc test.c -o test -I/Users/telliott_admin/Desktop/temp -L/Users/telliott_admin/Desktop/temp -lmymath
where mymath.a is renamed libmymath.a.
See link text for comments (search for "bad programming") on the practices of using -l:
In order for ld to find a library with -l, it must be named according to the pattern libyourname.a. Then you use -lmymath
So, there is no way to get it to take /temp/mymath.a with -l.
If you named it libmymath.a, then -L/temp -lmymath would find it.