I am trying to figure out what I am doing wrong when trying to use just flex in a Cmake file to build a shared lib.
i basically have the following
find_package(FLEX)
FLEX_TARGET(Test ../src/test.l ../src/test.c)
set(SRC_FILES mysource.c ${FLEX_Test_OUTPUTS})
add_libary(testlib ${SRC_FILES})
target_link_libraries(testlib crypto c ${FLEX_LIBRARIES})
this is giving me a problem saying it cant find ../src/test.c
any ideas how I can make sure Lex ran first? secondly,how can i pass my -L and -d options to lex (like I am doing in my normal, pre-cmake version of this makefile)
Why do you want output file to be in the source dir?
I'd recommend using ${CMAKE_CURRENT_BINARY_DIR}:
FLEX_TARGET(Test ../src/test.l ${CMAKE_CURRENT_BINARY_DIR}/../src/test.c)
As for
any ideas how I can make sure Lex ran first?
you don't need to do it, CMake can guess this dependency by it's own. I think the problem is either in using source dir for output file, or the ../src dir doesn't exist before flex runs.
secondly,how can i pass my -L and -d options to lex
List them after the output parameter:
FLEX_TARGET(Test ../src/test.l ${CMAKE_CURRENT_BINARY_DIR}/../src/test.c -L -d)
Related
I would like to compile CLIPS on Windows to get object files necessary to a binding with GNAT Ada.
I have downloaded the package clips_core_source_630.zip which provides core & makefiles directories
makefile.g++
makefile.gcc
makefile.lib
makefile.lib++
makefile.win
I tried to compile with MinGW through the commands :
mingw32-make makefile.gcc
or
mingw32-make makefile.g++
But the answer is always : Nothing to be done ! And of course no object file has been generated.
What am I doing wrong with that approach ?
Normally the argument to a make command is the desired target, not the name of the Makefile.
Since the file given as an argument already exists, there is nothing to be done.
If you want to build the project, try just a simple mingw32-make in the directory containing the Makefiles.
If that doesn't work, you can specify the file with -f.
mingw32-make -f makefile.g++
I use waf as my build system and I want to compile a small C program using Postgres. I have included postgres.h in my program so I need to find the path to it in my wscript file. I know that I can get the path I need by running:
pg_config --includedir-server
which gives me:
/usr/include/postgresql/9.3/server
So I thought I could use something like this:
cfg.check_cfg(
path='pg_config',
package='',
uselib_store='PG',
args='--includedir-server',
)
And then build my program by:
bld.program(
source=['testpg.c'],
target='testpg',
includes=['.', '../src'],
use=['PQ', 'PG'],
)
But this fails with postgres.h: No such file or directory. I ran ./waf -v and confirmed that the proper -I flag is not being passed to gcc. My guess is this happens because pg_config does not add a -I prefix to the path it returns. Is there a way I can make waf to add the prefix, or make pg_config to add it?
Should pg_config had the standard output of pkg_config like programs (ie outputs something like -Ixxx -Iyyy), your code would work, has check_cfg parse this kind of output.
As there is no complicated parsing, you can go for:
import subprocess
includes = subprocess.check_output(["pg_config", "--includedir-server"])
includes.replace("\n", "")
conf.env.INCLUDES_PG = [includes]
And then use it:
bld.program(
source=['testpg.c'],
target='testpg',
use=['PG'],
)
See the library integration in the waf book. It explains the naming rule that make it works.
You can write a small plugin to ease the use :)
I am on RHEL 6.0 and got hold of the source code for join command(hopefully from the right source!!). I rarely work on a C code and hence finding this difficult. I am trying to compile and run the C code for join, but running into compile time errors.
g++ join.c
join.c:19:20: error: config.h: No such file or directory
join.c:25:20: error: system.h: No such file or directory
join.c:27:25: error: hard-locale.h: No such file or directory
join.c:28:24: error: linebuffer.h: No such file or directory
join.c:29:24: error: memcasecmp.h: No such file or directory
join.c:30:19: error: quote.h: No such file or directory
join.c:31:21: error: stdio--.h: No such file or directory
join.c:32:22: error: xmemcoll.h: No such file or directory
join.c:33:21: error: xstrtol.h: No such file or directory
join.c:34:22: error: argmatch.h: No such file or directory
Since I am not aware of where to find these libraries(I did google for each one and they are spread all over different websites), can anyone please guide me as to how I can link these libraries together and compile the source code of join command?
This is not a linking problem as you suggest. Instead, you get these errors because g++ can't find these files: config.h, system.h, ..., that are #included (indirectly) by join.c.
What you could do is find these files on your system, and then add as many -I<directory> options behind the g++ as there were directories you found these files in. Do man g++ for more info.
You'll also need to find the where the libraries are you need to link against. So you'll need to specify more than -I's.
On the other hand, aren't there 'configure' or other package files? Normally you don't have to specify compiler flags (like this -I) by hand. Instead, it's common that for example Makefile's are generated from such a configuration file, after which you just have to type make.
I advise you to get someone that has done this before, because you don't seem to understand the basics of C program compilation. This can cost you a lot of your precious time without results. But good luck anyway!
Perhaps you don't have everything in place to compile your code. Try installing the build-essential package.
sudo yum install build-essential
On a relevant note, I'm not aware of the script join.c but if you are looking for a way to concatenate a bunch of files together, you can do cat FILE1 FILE2 FILE3 > BIG_FILE where FILE1 FILE2 FILE3 are the files you want to join them. Under RHEL 6.0, you can use asterisks too, if there is a pattern. For example, cat FILE.00* > BIG_FILE
I'm trying to accelerate a key function in a c project (not c++) using CUDA.
For some reason, i can't get the Makefile's to recognise the .cu extension when I change the name of one of the files to .cu.
It's using a configure script and .am/.in/.deps files, which I don't really understand all that well, but basically I grepped references to file.c and changed them all to file.cu, but it produces a file.o: File Not Found error.
Top level make file
https://www.dropbox.com/s/g282qvbdu8pdas0/Makefile
Src folder makefile
https://www.dropbox.com/s/b4pq026od8gauqi/Makefile
The search command I used was
grep -R -i "file.c"
and I simply changed them all to file.cu, then re-ran configure, make clean, make all - result is File Not Found.
I suppose it must be something to do with extensions being ignored/accepted by the Makefile, but as it's been a long time since I've programmed in C and I've never used such complex Makefiles I don't know how to fix it.
Any ideas?
*PS Also, file.cu has compile errors at the moment, but the error message I'm getting is File Not Found, so I think that's not the problem.
You need to have a rule to build o file from a cu file:
cudafile.o: cudafile.cu
nvcc $(NVCC_FLAGS) -c %< -o $#
So you also need to specify the rule for the cu file, and use nvcc for compilation.
The following guide seems to cover it...
http://mcclanahoochie.com/blog/2011/02/automake-and-cuda/
Actually, most of the advice given in the link seems unnecessary for basic compilation, but for some reason I found that when I re-created the config file using autoconf it worked. No explanation comes to mind.
hello everyone
i try to debug a program, which have been installed by makefile.
it have a binary file of OpenDPI_demo.o and a shell shellscript OpenDPI_demo.
when i gdb OpenDPI_demo.o,i have a problem. i can't run it. the error is:
Starting program: /home/lx/ntop/test/opendpi/src/examples/OpenDPI_demo/OpenDPI_demo.o
/bin/bash: /home/lx/ntop/test/opendpi/src/examples/OpenDPI_demo/OpenDPI_demo.o：can't execute the binary file.
please tell me why. actually i can run the program by ./OpenDPI_demo.
thank you.
Based on the extension, the file is an object file. It is used by the linker (alongside other object files) to produce an executable. It's the real executable the one you want to run/debug.
This is another example of difficulties encountered with programs using libtool.
the file OpenDPI_demo alongside OpenDPI_demo.o is actually, as you said, a shell script which wraps the execution of the real compiled file, probably in .libs/OpenDPI_demo.
libtool needs this wrapper to adjust the runtime library paths and such so that you can execute the program transparently, as if it was actually installed on your system.
The way to correctly debug this application is not
/home/lx/ntop/test/opendpi $ gdb src/examples/OpenDPI_demo/.libs/OpenDPI_demo
but rather using libtool --mode=execute on the shell script, like the following (it's an example):
/home/lx/ntop/test/opendpi $ ./libtool --mode=execute gdb --args \
src/examples/OpenDPI_demo/OpenDPI_demo -f capture.pcap
Suggest you use
gdb OpenDPI_demo
instead
In your makefile if it depens on the object, make it depend on OpenDPI_demo, e.g.