I'm on a Windows machine and use MinGW, attempting to compile a hello world program that uses a shared library. After an absurd amount of attempts, I found out the following:
Manually compiling it with gcc and providing -I and -L flags for the required directories works fine.
Using the msys make.exe file provided under the MinGW/msys/1.0/bin installation directory properly executes a Makefile with no problems
Using the mingw32-make.exe provided under MinGW/bin doesn't work properly when trying to build using the same Makefile. From my understanding, it doesn't parse the -I and -L flags at all. It works fine if I add the dependencies (both includes and libs) under their respective MinGW directories.
These past few days while I was trying and familiarizing myself with these tools (I'm comfortable with C's syntax but know about nothing past that) I read many guides and no one seemed to have this issue (from the few that actually attempted this on a Windows machine without using an IDE). Did I miss something? Is my MinGW installation known to have this issue?
Note that at first I was attempting to compile the project using the 64-bit version of the library but failed. I'm guessing this means that I have a 32-bit MinGW installation.
Knowing that some will ask to see the Makefile:
CC = gcc
MY_LIB = -L/e/C_Projects/Libraries/MySharedLib/lib -lMyLibName
MY_INCLUDE = -I/e/C_Projects/Libraries/MySharedLib/include
CFLAGS = -Wall -c $(MY_INCLUDE)
LDFLAGS = -lmingw32 -mwindows $(MY_LIB)
EXE = Test.exe
all: $(EXE)
$(EXE): main.o
$(CC) $< $(LDFLAGS) -o $#
main.o: main.c
$(CC) $(CFLAGS) $< -o $#
clean:
del *.o && del $(EXE)
The error produced by mingw32-make.exe is the following
main.c:1:22: fatal error: MyLib.h: No such file or directory
#include <MyLib.h>
^
compilation terminated.
Makefile:19: recipe for target 'main.o' failed
mingw32-make: *** [main.o] Error 1
Related
I am porting a project written in C from a CentOS 7 (Core) to an Ubuntu 20.04.1 LTS (Focal Fossa) system. The project relies heavily on the <cpuset.h> library, and compiles and executes correctly on the CentOS system. However, when I try to use functions from cpuset.h on the Ubuntu system, I get 'undefined reference' errors.
The following code, stored in file test.c, compiles and runs correctly on CentOS:
#define _GNU_SOURCE
#include<stdio.h>
#include <cpuset.h>
int main(){
int x = cpuset_version();
printf("cpuset lib version: %d\n",x );
return 0;
}
How I compile:
gcc -Wall -O2 -std=gnu99 -g -lcpuset test.c -o test
Output:
[xxxx#CentOS]$ ./test
cpuset lib version: 3
However, when I try to compile the same test.c file on the Ubuntu system, I get this error:
xxxx#Ubuntu:$ gcc -Wall -O2 -std=gnu99 -g -lcpuset test.c -o test
/usr/bin/ld: /tmp/ccpxlk4F.o: in function `main':
test.c:8: undefined reference to `cpuset_version'
collect2: error: ld returned 1 exit status
Furthermore, this is not limited to the <cpuset.h> library. I tried to use a simple function from <pthread.h> and it also gave me the same error. Can anyone help with identifying why I cannot use shared libraries on the Ubuntu system? Thanks in advance
Since OP's issue is wrong order of parameters to GCC (many guides do show an incorrect order!), as discussed in the comments to the question, I believe showing a minimal Makefile to handle these is warranted:
CC := gcc
CFLAGS := -Wall -O2 -g
LDFLAGS := -lcpuset
TARGETS := test
.PHONY: all clean
all: $(TARGETS)
clean:
rm -f *.o $(TARGETS)
%.o: %.c
$(CC) $(CFLAGS) -c $^
test: test.o
$(CC) $(CFLAGS) $^ $(LDFLAGS) -o $#
Note that the indentation in Makefiles must use Tabs and not spaces. Since this forum converts Tabs to spaces, you will need to fix the above makefile, for example by running sed -e 's|^ *|\t|' -i Makefile.
If you want to compile say foo.c directly to an executable, the recipe is
foo: foo.c
$(CC) $(CFLAGS) $^ $(LDFLAGS) -o $#
You only need to run make (it defaults to using the Makefile in the current directory, and the default target is the first one, above the one named all), to recompile the TARGETS (here, test, but you can supply more by just adding them space-separated to the line).
You can also run make clean test to rebuild test from "scratch", i.e. removing all temporary files and all targets first.
You can override variables like CFLAGS by simply supplying them on the command line; for example, make CFLAGS="-Wall -Wextra -Os" clean all to recompile everything with different compilation flags.
what i'm doing wrong?
And can you send some helpful links to make my work with makefiles easier and better?
get_next_line.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
Makefile:27: recipe for target 'gnl' failed
make: *** [gnl] Error 1
+++
SRC = gnl.c
OBJ = $(SRC:.c=.o)
INCLUDES = gnl.h
NAME = gnl
CFLAGS = -Wall -Werror -Wextra
CC = gcc
DIR = LIBFT
%.o: %.c $(SRC) $(INCLUDES)
$(CC) $(CFLAGS) -c $<
all: $(NAME)
$(NAME): $(OBJ)
make -C $(DIR)
$(CC) $(CFLAGS) -o $(NAME) $(OBJ) -L. $(DIR)/libft.a
clean:
make clean -C $(DIR)
rm -f $(OBJ)
fclean:
make fclean -C $(DIR)
rm -f $(NAME)
re: fclean all
This is not a make error by itself. It says
get_next_line.o: file not recognized: File format not recognized
so that is your problem. Somehow you managed to have a .o file in your directory that is corrupted. Remove it and things will go better.
You have misunderstood the error message. The error message is referring to the file get_next_line.o, not the makefile.
It is the linker (ld) that is reporting the error not make. The command that has failed is that for the target gnl.
It can even be simpler...
It just happened to me with a Makefile.
In the line (in the Makefile) that creates the executable, where there are different names of objects .o, there was a typo. I left the name of the file .cu (CUDA format) instead of .o.
I ran into this error recently, and I have a couple of suggestions that might help. My problem was not a bad .o file, but rather a 32-bit installation rather than a 64-bit installation. If this is the case for you, too, you might get more complete functionality by trying this solution.
In my case, the makefile(s) in question needed different CFLAGS depending on whether the installation was 64-bit or 32-bit. Here are some lines from the README of the project I was trying to make.
By default, the C/C++ software are compiled in 32 bits with the options (-Os) but can be compiled in 64 bits, -m64 is added to the CFLAGS variable in <certain makefiles in the project are listed>
My suggestion is to first try adding -m64 to your CFLAGS. If that doesn't work, delete the -m64 and replace it with -Os.
That is, first try having the following line:
CFLAGS = -g3 -Wall -Wextra -fPIC -DREPLICATION_ENABLED -DJOURNALING_ENABLED -m64
Then, from the command line, run
make clean
Followed by whatever make commands you use for your install.
If that doesn't work, change the line in question to
CFLAGS = -g3 -Wall -Wextra -fPIC -DREPLICATION_ENABLED -DJOURNALING_ENABLED -Os
Then make clean and the other make stuff.
If some of the C objects are 64-bit and some are 32-bit (I don't know if such a situation actually exists), you might have to do something different.
This worked in my case, details of which you can see here.
Please comment to let me know if it works for you.
I downloaded the C source code for single-threaded Linux versions of cubist software. what the code does is it takes the input data and generates the regression tree model.
when compiling the source code using Ubuntu terminal it generated the Executable file with out error.
Here is the makefile
CC = gcc -ffloat-store
OFLAGS = -O3
CFLAGS = -DVerbOpt -g -Wall -O0
LFLAGS = $(S)
SHELL = /bin/csh
src =\
global.c\
xval.c\
cubist.c\
sort.c\
construct.c\
predict.c\
stats.c\
discr.c\
rules.c\
contin.c\
formrules.c\
formtree.c\
getdata.c\
getnames.c\
implicitatt.c\
instance.c\
modelfiles.c\
prunetree.c\
regress.c\
trees.c\
update.c\
utility.c
obj =\
global.o cubist.o construct.o\
formtree.o prunetree.o stats.o discr.o contin.o\
trees.o\
formrules.o rules.o\
instance.o\
predict.o\
regress.o\
xval.o\
getnames.o getdata.o implicitatt.o sort.o\
modelfiles.o\
update.o utility.o\
all:
make cubist
$(CC) $(LFLAGS) $(OFLAGS) -o summary summary.c -lm
# debug version (including verbosity option)
cubistdbg:\
$(obj) defns.i extern.i text.i Makefile
$(CC) $(CFLAGS) -o cubistdbg $(obj) -lm
# production version
cubist:\
$(src) defns.i text.i Makefile
cat defns.i $(src)\
| egrep -v 'defns.i|extern.i' >cubistgt.c
$(CC) $(LFLAGS) $(OFLAGS) -o cubist cubistgt.c -lm
strip cubist
rm cubistgt.c
$(obj): Makefile defns.i extern.i text.i
.c.o:
$(CC) $(CFLAGS) -c $<
When i try to do similar work in windows i got error message
$ make all
make cubist
make: /bin/csh: Command not found
make: *** [Makefile:56: all] Error 127
But when i try by removing SHELL = /bin/csh from Makefile it worked. My question here is does it has negative effect on the software or
how could i fix it with out removing SHELL = /bin/csh.
thank you very much
My guess is that by removing the line SHELL = /bin/csh your result is ok.
/bin/csh is a shell (command line interface, command processor, command prompt) used mostly in unix. In your makefile it is defined, but not referenced (not used).
Sometimes makefiles can need a shell (command processor) in order to execute some task, but it is up to the makefile - I mean, the person writing the makefile chooses to use that functionality or not and, if used, can (or must) specify which shell to use. This is not your case, now.
I'm trying to compile code from a backtrace project https://code.google.com/p/backtrace-mingw/ which is written for MinGW, but using MinGW-w64.
My old install and fresh install of MinGW-w64 produce the same problem. Path is set in path variables, and also in command prompt:
C:\mingw-w64\i686-4.9.2-win32-sjlj-rt_v3-rev1\mingw32\bin
and C:\mingw-w64\i686-4.9.2-win32-sjlj-rt_v3-rev1\mingw32 although this one isn't needed.
This is the makefile of that project:
.PHONY: all clean
all : backtrace.dll test.exe
backtrace.dll : backtrace.c
gcc -O2 -shared -Wall -o $# $^ -lbfd -lintl -liberty -limagehlp
test.exe : test.c
gcc -g -Wall -o $# $^
clean :
-del -f backtrace.dll test.exe
When compiling I get the warning:
backtrace.c:23:17: fatal error: bfd.h: No such file or directory #include < bfd.h>`
Which is weird because that file exists in ../mingw32/include folder.
If I add this when compilind the dll: -IC:\mingw-w64\i686-4.9.2-win32-sjlj-rt_v3-rev1\mingw32\include it continues but stops at the directive: #error config.h must be included before this header and config.h is missing in MinGW-w64
Any ideas?
That path is definetely missing from gcc include paths in mingw. I don't know why. You have to add it yourself in any way you like: cmake recipe, autoconf recipe, CFLAGS, CPATH, gcc specs.
And, as far as I remember, it uses only HAVE_STRINGIZE macro from config.h and it is used only to define CONCAT4 macro, that's not used anywhere in bfd.h. So, it's safe to cheat a little and put
#define PACKAGE package
before including bfd.h
add this to the end of the compile statement:
-I./mingw32/include
so the whole compile statement would be:
gcc -g -Wall -o $# $^ -I./mingw32/include
so the compiler knows where to find the include files
I am modifying an old makefile in order to build a C extension for postgreSQL. The Makefile currently looks like this:
PGLIB = /usr/lib/postgresql/8.4/lib
PQINC = /usr/include/postgresql/8.4/server
CC=gcc
override CFLAGS+= $(CFLAGS_SL) -DPG_AGGREGATE
SHLIB = pg_myextlib
SRC = foo.c \
foobar.c
OBJS = foo.o \
foobar.o
all: $(OBJS)
$(CC) -shared -o $(SHLIB)$(DLSUFFIX) $(OBJS) -I$(PQINC)
cp *.so $(PGLIB)
clean:
rm -f $(SHLIB) $(OBJS)
The error I get when I run make is:
common.h:58:22: error: postgres.h: No such file or directory
Which suggests that the include path is not being added (the file exists in $PQINC).
Its a long time since I wrote the Makefile - and I haven't written many since. As an aside, I am pretty sure that 'shared' is not the gcc flag to build shared libs on Ubuntu (my current dev box) - I think the flag should be 'fPIC' - can someone confirm this?
I am runing gcc v4.4.3 on Ubuntu 10.0.4 and compiling for use with PG 8.4
Try moving the -I$(PQINC) from target all to the end of line that starts with override CFLAGS.
Placing -Isomething on the compiler line which turns object files, like those in $(OBJS), into executable will have no effect whatsoever.
You need to do it when you compile the source files.
Since your makefile doesn't explicitly show the rule for processing source files, it may well be using a default one, which is incredibly unlikely to know about PQINC.
You seem to be using the default rules to build foo.o from foo.c, which doesn't have your -I. Try adding the following rule to your Makefile:
.c.o:
$(CC) $(CFLAGS) -c $< -o $# -I$(PQINC)