I'm very new to Makefiles and I try to migrate this Makefile written for Linux (make) to a windows environment (nmake). I did not write this file so obviously I'm also trying to figure out the meaning of those lines.
Any chance you'd help me with the "translation" ?
DIR = src
BIN_PATH_DEST = /usr/local/bin
LIB_PATH_DEST = /usr/local/libs
CFLAGS = -DDISPLAY_TIME -DWRITE_TXT_FILES -DDISPLAY_BOUNDINGBOX
libs/libenvis3D_co.a:
cd $(DIR); make CFLAGS="$(CFLAGS)" ../libs/libenvis3D_co.a
bin/geobox_envis3D_co: main3D_co.c libs/libenvis3D_co.a
gcc -Wall $(CFLAGS) main3D_co.c libs/libenvis3D_co.a -lm -llapack -o bin/geobox_envis3D_co
install3D_co: bin/geobox_envis3D_co
cd $(DIR); make CFLAGS="$(CFLAGS)" ../libs/libenvis3D_co.a
make bin/geobox_envis3D_co
cp bin/geobox_envis3D_co $(BIN_PATH_DEST)
clean:
cd $(DIR); make clean
I also tried to download and use GNU make as described in this page :
How to run a makefile in Windows?
but I'm being throw the error :
C:\users\...>make -f Makefile
cd src; make CFLAGS="-DDISPLAY_TIME -DWRITE_TXT_FILES -DDISPLAY_BOUNDINGBOX" ../libs/libenvis3D_co.a
Le chemin d’accès spécifié est introuvable. (path to file not found).
make: *** [libs/libenvis3D_co.a] Erreur 1
Thanks for your input and help !
Related
I am trying to build a Xilinx XDMA driver for Yocto, using their supplied makefile. When I run my recipe the build fails with the following errors:
DEBUG: Executing shell function do_compile
NOTE: make -j 32 KERNEL_SRC=./tmp/work-shared/intel-corei7-64/kernel-source
KERNEL_PATH=./tmp/work-shared/intel-corei7-64/kernel-source
KERNEL_VERSION=5.10.78-intel-pk-standard CC=x86_64-poky-linux-gcc
-fuse-ld=bfd
-fmacro-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0=/usr/src/debug/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0
-fdebug-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0=/usr/src/debug/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0
-fdebug-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/recipe-sysroot=
-fdebug-prefix-map=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/recipe-sysroot-native=
-fdebug-prefix-map=./tmp/work-shared/intel-corei7-64/kernel-source=/usr/src/kernel LD=x86_64-poky-linux-ld.bfd
AR=x86_64-poky-linux-ar
O=./tmp/work-shared/intel-corei7-64/kernel-build-artifacts KBUILD_EXTRA_SYMBOLS=
Makefile:17: XVC_FLAGS: .
make -C /lib/modules/5.13.0-40-generic/build
M=./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma modules
make[1]: Entering directory '/usr/src/linux-headers-5.13.0-40-generic'
make[2]: Entering directory './tmp/work-shared/intel-corei7-64/kernel-build-artifacts'
./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/Makefile:17: XVC_FLAGS: .
CC [M] ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/libxdma.o
CC [M] ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/xdma_cdev.o
x86_64-poky-linux-gcc: error: missing argument to '-gdwarf-'
CC [M] ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/cdev_ctrl.o
make[3]: *** [/usr/src/linux-headers-5.13.0-40-generic/scripts/Makefile.build:281: ./tmp/work/intel_corei7_64-poky-linux/xdma-driver-mod/1.0+gitAUTOINC+8d75946900-r0/git/linux_driver/xdma/libxdma.o] Error 1
make[3]: *** Waiting for unfinished jobs....
x86_64-poky-linux-gcc: error: missing argument to '-gdwarf-'
ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
I have no idea why this happens as it is not something I have specifically enabled. I have searched through the module.bbclass file but I couldn't see anything obvious. I believe that something needs to be configured such that the -gdwarf- actual ends up being set to a valid value (e.g. -gdwarf-2 or -gdwarf-4 etc.)
A grep through the poky repo for dwarf did not reveal anything neither did a search of /usr/src/linux-headers-5.13.0-40-generic/scripts/.
My bitbake recipe is as follows:
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=441c1ecbc199a036abf37f3aa47c5f34"
SRC_URI += https://github.com/Xilinx/dma_ip_drivers.git;protocol=ssh;nobranch=1;branch=master"
# Modify these as desired
PV = "1.0+git${SRCPV}"
SRCREV = "8d7594690058dfa828accc02ac81348e416ffe38"
S = "${WORKDIR}/git/xdma/linux-driver/xdma"
RPROVIDES_${PN} += "xdma"
inherit module
EXTRA_OEMAKE_task-install:append = " -C ${STAGING_KERNEL_DIR} M=${S}"
EXTRA_OEMAKE += "KDIR=${STAGING_KERNEL_DIR}"
The makefile is the standard one from GitHub. The driver builds correctly for Ubuntu using make and I can also build the module if I change my recipe such that it does not include inherit module; this change will build the module (xdma.ko) but does to install it in the roofs. I am also not sure if inherit module includes additional functionality which may be rewired.
How to I either:
prevent / disable the -gdwarf flag being generated
configure the recipe that the -gdwarf- resolves to something valid
View the actual command being invoked that is causing the issue.
Attempts to build the xdma.ko module without the inherit module result in an invalid binary being built, i.e. when I try an load the module on the target I get:
insmod xdma.ko
insmod: ERROR: could not insert module xdma.ko: Invalid module format
Which indicates that the module is compiled from the wrong target.
inherit module is required when building kernel modules for Yocto. If it is omitted the build modules is not compatible with the target.
Workaround for the -gdwarf- error was to manually write a new makefile which is compatible with Yocto:
TARGET_MODULE:=xdma
topdir := $(shell cd $(src)/.. && pwd)
EXTRA_CFLAGS := -I$(topdir)/include
SRC := $(shell pwd)
$(TARGET_MODULE)-objs := libxdma.o xdma_cdev.o cdev_ctrl.o cdev_events.o cdev_sgdma.o cdev_xvc.o cdev_bypass.o xdma_mod.o xdma_thread.o
obj-m := $(TARGET_MODULE).o
all :
$(MAKE) -C $(KERNEL_SRC) M=$(SRC)
modules_install:
$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
clean:
rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
rm -f Module.markers Module.symvers modules.order
rm -rf .tmp_versions Modules.symvers
This makefile correctly builds the Xilinx XDMA driver for Yocto. I can confirm that the driver works with Kintex-KC705 FPGA development card.
I am trying to create shared library i.e. .so from C++ code using Git Bash shell in Windows 10.
I use Makefile for compiling C++ code in Windows 10. Running make through Git bash shell.
Code compiles without any issue and creates object files without fail.
But it fails while creating .so file throwing following error. Following is part of Makefile in which target VLIB_SHARED_LIBRARY is causing this error.
VLIB_SO_DIR = .
VLIB_SHARED_LIBRARY = $(VLIB_SO_DIR)/libvxxx.so
CXX = g++
CXXFLAGS = -Wall -std=c++11 -O2 -D_7ZIP_ST -fPIC
LDFLAGS = -shared
OBJECT_FILES = a.o b.o c.o d.o .. z.o
all: init $(VLIB_SHARED_LIBRARY )
release: init $(VLIB_SHARED_LIBRARY )
$(VLIB_SHARED_LIBRARY): $(OBJECT_FILES) \n
$(CXX) $(LDFLAGS) -o $(VLIB_SHARED_LIBRARY) $(OBJECT_DIR)/*.o
process_begin: CreateProcess(C:\Program, C:/Program Files/Git/usr/bin/sh.exe -c "g++ -shared -o C:/XXXX_YYYY/bbbb/bin_linux/libyyyy.so C:/XXXX_YYYY/bbbb/bin_linux/obj/*.o", ...) failed.
make (e=193): Error 193
Same Makefile works fine in actual Linux Ubuntu OS but fails in Windows 10.
How to fix this error ?
The reason I suggested whitespace issues in my comment above is that the error message CLEARLY shows that it's a whitespace problem:
CreateProcess(C:\Program, C:/Program Files/Git/usr/bin/sh.exe ...
There is a space in this path to sh.exe, and the first argument printed here C:\Program quite clearly shows that the path has been truncated at the space.
I thought maybe your makefile was setting SHELL to some value but it doesn't appear to be. All I can suggest is either (a) remove C:\Program Files\Git\usr\bin from your %Path%, or (b) re-install Git into a path that doesn't contain whitespace so that you don't hit this problem.
I want to recompile an old Fortran 77 code (having a lot of subroutines) via gfortran in MingW bash platform in windows 10. There is a makefile among the old code files which is attached here:
Version = 2.10
FOR = df
FFLAGS = /optimize:5
INSTALL = move
DELETE = del
COPY = copy
# these libraries must already exist somewhere
# where ld can find them
LIBS = \rfem\lib\GAF77.lib \rfem\lib\VFEM.lib DFPORT.lib
# where the final program is to be placed
BINDIR = \rfem\bin
# where the cat man pages are to go
CATDIR = \rfem\doc
# here are the files needed to construct Rslope2D
FILES = mrslope2d.f \
chknxe.f dismsh.f echosd.f fem2det.f fem2rf.f \
fem2sd.f feminit.f mesh.f openin.f opensd.f \
pltfld.f readsd.f rect.f setsd2.f sim2sd.f \
statsd.f szchk.f vecmsh.f
OBJS = mrslope2d.obj \
chknxe.obj dismsh.obj echosd.obj fem2det.obj fem2rf.obj \
fem2sd.obj feminit.obj mesh.obj openin.obj opensd.obj \
pltfld.obj readsd.obj rect.obj setsd2.obj sim2sd.obj \
statsd.obj szchk.obj vecmsh.obj
rslope2d.exe: $(OBJS)
link /out:rslope2d.exe $(OBJS) $(LIBS)
$(DELETE) $(BINDIR)\rslope2d.exe
$(INSTALL) rslope2d.exe $(BINDIR)
$(COPY) rslope2d.1 $(CATDIR)
clean:
$(DELETE) *.obj
After navigating to the directory where this makefile is located and typing make in the MingW window (to recompile the main code),
I encounter the following error:
No rule to make target 'mrslope2d.obj', needed by 'rslope2d.exe'. Stop.
I am a beginner in Fortran, so apologies if the question is simple.
Looking forward to your suggestions and guidance as I do not know how to resolve this.
Thanks
OS: FreeBSD 11.0-RELEASE
I have the following directory structure:
/xxx/obj/
/xxx/src/deep.cpp
/xxx/flat.cpp
/xxx/makefile
The content of makefile is as follows:
flat.out: flat.o
deep.out: src/deep.o
I have no problem building flat:
/xxx $ make flat.out
c++ -O2 -pipe -c /xxx/flat.cpp -o flat.o
cc -O2 -pipe flat.o -o flat.out
/xxx $ ls obj
flat.o flat.out
But when I try to build deep it fails:
/xxx $ make deep.out
c++ -O2 -pipe -c /xxx/src/deep.cpp -o src/deep.o
error: unable to open output file 'src/deep.o': 'No such file or directory'
1 error generated.
*** Error code 1
Stop.
make: stopped in /xxx
If I then create /xxx/obj/src manually it succeeds:
/xxx $ mkdir obj/src
/xxx $ make deep.out
c++ -O2 -pipe -c /xxx/src/deep.cpp -o src/deep.o
cc -O2 -pipe src/deep.o -o deep.out
/xxx $ ls obj
deep.out flat.o flat.out src
/xxx $ ls obj/src
deep.o
According to this source bmake (aka bsdmake?) supports automatic creation of out-of-source OBJDIRs, but I cannot figure out how exactly.
How do I configure bmake to create the relevant directories automatically, in the general case?
Automatic creation of out-of-source OBJDIRs is supported but not in the sense you seem to expect it. Creation of out-of-source OBJDIRs can be implemented with bmake(1) directives but is not supported by the bmake(1) program itself. That said,
If you use bmake(1) directives shipped with FreeBSD to build your project, then the creation of OBJDIRs is supported and implemented by the obj target, so that the command make obj will create the OBJDIRs. See the file bsd.obj.mk for further documentation and implementation details. FreeBSD sources contain a lot of examples of programs using these directives to build.
If you use bmake(1) directives shipped as the (portable) bsdowl package, then the creation of OBJDIRs is supported and implemented by the target obj so that the command make obj or the command make preparatives using a more general target will create the OBJDIRs. The example directory contains several C-based examples showing how to prepare your Makefiles to build your project with the bsdowl package.
If you use custom bmake(1) directives, then you will have to implement a target taking care of this creation yourself. The file bsd.obj.mk is definitely a good source to get started with this.
An important point to note, is that bmake(1) determines its actual working directory before processing any targets, which means that it is almost always the right thing to do to execute the target requesting the creation of OBJDIRs on its own. Because of this, the command bmake obj all from your example would fail with the same error message you reported above. The correct invocation would instead be bmake obj && bmake all, since the second bmake(1) process has now the chance to change to the OBJDIR created by the previous run.
I'm using QtCreator (MinGW32 kit) on Windows and trying to make qt project with jom. Project build succeds. But! If I use silent mode :
CONFIG += silent
- build fails. If I look at Compile Output I'll see the error:
jom: .....\Makefile Error
Unexpected appearance: &&.
Also what I'll see in Makefile (I'm only displaying blocks where chars "&&" appear):
Compiler, tools and options
CC = #echo compiling $< && gcc
CXX = #echo compiling $< && g++
LINKER = #echo linking $# && g++
And then Build rules:
#echo moc BooleanSimulationModule.h && C:\Qt\Qt5.6.0\5.6\mingw49_32\bin\moc.exe $(DEFINES) -D__GNUC__ -DWIN32 -IC:/Qt/Qt5.6.0/5.6/mingw49_32/mkspecs/win32-g++ -IE:/qtregistrar/plugins/BooleanSimulationModule -IE:/qtregistrar/tools/widgets/QRWidgets/src -IE:/qtregistrar/tools/widgets/InfPlotWidget -IE:/qtregistrar/reglib -IC:/Qt/Qt5.6.0/5.6/mingw49_32/include -IC:/Qt/Qt5.6.0/5.6/mingw49_32/include/QtWidgets -IC:/Qt/Qt5.6.0/5.6/mingw49_32/include/QtGui -IC:/Qt/Qt5.6.0/5.6/mingw49_32/include/QtANGLE -IC:/Qt/Qt5.6.0/5.6/mingw49_32/include/QtCore BooleanSimulationModule.h -o moc_BooleanSimulationModule.cpp
Does anyone have any ideas why jom can't resolve command "&&" and how to fix this?
By the way, mingw32-make can build such Makefile without any probles.