I have a project with some sub-projects,
I have configured with the following commands
meson project/builddir --cross-file qnx7.meson --buildtype=plain
If I have understood well the use of buildtype=plain,
I should not find in ARGS the default c flags both in the main project and also in the sub-projects ones.
But then when I go to look at the build.ninja file I got the unwanted default cflags.
Any idea how to solve this issue?
The meson version is
meson -v
0.55.3
Related
I have a project which uses libibverbs. I have to compile this project on a server to run it there. The server has libibverbs installed system-wide, but unfortunately it doesn't support a feature which I need.
I decided to compile and use my own version of libibverbs, which has the corresponding feature. So I compiled the library, installed it to my home directory, and updated following environment variables: PATH, LD_LIBRARY_PATH, C_INCLUDE_PATH, LIBRARY_PATH, CPLUS_INCLUDE_PATH
Now I have to compile my project. First I call configure and it fails with following error message:
conftest.c:(.text.startup+0x7): undefined reference to `ibv_open_xrc_domain'
This is the symbol, which is missing in the system-wide version, but is present in the version I installed. First entry in LIBRARY_PATH is the path to the new libibversion, so I expected it is going to be used first, but it seems that the old version is used anyway.
Compilation command which ./configure uses, contains flag -L/libibverbs/1.1.4/lib, which points to the directory with the new library version. This flag goes just after -L/usr/lib/../lib64 which point to the directory, with system-wide libibverbs
If I put -L with new version in the end of command, the conftest compiles successfully.
To be clear following fails: https://gist.github.com/planetA/a421669269b14e69026c53f56fa45b2b
And following works:
https://gist.github.com/planetA/3b0e22bf6aca3a1c67f30bfa3666d9a8
Could you help me to enforce picking the new version of the library in a way that configure catches it?
LD_LIBRARY_PATH specifies directories to be searched, before the
defaults, for a library that is to be loaded in a process at runtime.
It does not affect the directories that are searched for a library
in order to link it at buildtime.
The linker searches for libraries in the directories that are specified
with the -Ldir option in its commandline, before it searches its
default directories. Your configure script tests whether it can find a libibverbs library in the linker's search directories that defines the function
ibv_open_xrc_domain, and fails because it cannot. The value of LD_LIBRARY_PATH does
not matter to this test.
For GNU make, the -L-options it should pass to the linker
are conventionally specified in the environment variable LDFLAGS. GNU autoconf - which
generates your configure script - follows this convention. autoconf generates
the configure script from the project's configure.ac file.
So, if your want your modified package to generate a generate a configure
script such that running ./configure will in turn generate makefiles
in which -L/my/library/version/is/here is passed to the linker then
you need to modify the project's configure.ac like:
LDFLAGS="$LDFLAGS -L/my/library/version/is/here"
and you need to do this in the configure.ac before it runs the test for
the libibverbs library. After making this change you will need to reconfigure
the package by running autoreconf in the project directrory, to regenerate
the configure script.
If you don't want to change the configure.ac like this then you can achieve the same
effect by:
./configure LDFLAGS="$LDFLAGS -L/my/library/version/is/here"
or:
export LDFLAGS="$LDFLAGS -L/my/library/version/is/here"
... # in same shell or a subshell
./configure
Then until the next time you run the configure script the project's makefiles
will pass -L/my/library/version/is/here to the linker. But the next time
you run ./configure you must remember to set LDFLAGS in the same way, or
the regenerated makefiles will revert to the default behaviour.
I'm using go 1.5 and I'm cross compiling like specified here.
The problem is that when compiling the project it will override the binary the last compilation created. Moreover - I will never know which OS/ARCH the executable file that I'm running was compiled to (in any case that is not windows).
Is there a way to rename the file at compile command?
You could use the "-o" argument, like this:
GOOS=linux GOARCH=386 CGO_ENABLED=0 go build -o test/output/myapp
From the page you linked to:
-o may be used to alter the name and destination of your binary, but remember that go build takes a value that is relative to your $GOPATH/src, not your working directory, so changing directories then executing the go build command is also an option.
If you use GOOS and GOARCH in the name, you should be able to achieve what you want.
Is there a way to configure CLion to use a local makefile to compile code, rather than CMake? I can't seem to find the way to do it from the build options.
Update: If you are using CLion 2020.2, then it already supports Makefiles. If you are using an older version, read on.
Even though currently only CMake is supported, you can instruct CMake to call make with your custom Makefile. Edit your CMakeLists.txt adding one of these two commands:
add_custom_target
add_custom_command
When you tell CLion to run your program, it will try to find an executable with the same name of the target in the directory pointed by PROJECT_BINARY_DIR. So as long as your make generates the file where CLion expects, there will be no problem.
Here is a working example:
Tell CLion to pass its $(PROJECT_BINARY_DIR) to make
This is the sample CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.4)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest COMMAND make -C ${mytest_SOURCE_DIR}
CLION_EXE_DIR=${PROJECT_BINARY_DIR})
Tell make to generate the executable in CLion's directory
This is the sample Makefile:
all:
echo Compiling $(CLION_EXE_DIR)/$# ...
g++ mytest.cpp -o $(CLION_EXE_DIR)/mytest
That is all, you may also want to change your program's working directory so it executes as it is when you run make from inside your directory. For this edit: Run -> Edit Configurations ... -> mytest -> Working directory
While this is one of the most voted feature requests, there is one plugin available, by Victor Kropp, that adds support to makefiles:
Makefile support plugin for IntelliJ IDEA
Install
You can install directly from the official repository:
Settings > Plugins > search for makefile > Search in repositories > Install > Restart
Use
There are at least three different ways to run:
Right click on a makefile and select Run
Have the makefile open in the editor, put the cursor over one target (anywhere on the line), hit alt + enter, then select make target
Hit ctrl/cmd + shift + F10 on a target (although this one didn't work for me on a mac).
It opens a pane named Run target with the output.
Newest version has better support literally for any generated Makefiles, through the compiledb
Three steps:
install compiledb
pip install compiledb
run a dry make
compiledb -n make
(do the autogen, configure if needed)
there will be a compile_commands.json file generated
open the project and you will see CLion will load info from the json file.
If you your CLion still try to find CMakeLists.txt and cannot read compile_commands.json, try to remove the entire folder, re-download the source files, and redo step 1,2,3
Orignal post: Working with Makefiles in CLion using Compilation DB
To totally avoid using CMAKE, you can simply:
Build your project as you normally with Make through the terminal.
Change your CLion configurations, go to (in top bar) :
Run -> Edit Configurations -> yourProjectFolder
Change the Executable to the one generated with Make
Change the Working directory to the folder holding your executable (if needed)
Remove the Build task in the Before launch:Activate tool window box
And you're all set! You can now use the debug button after your manual build.
Currently, only CMake is supported by CLion. Others build systems will be added in the future, but currently, you can only use CMake.
An importer tool has been implemented to help you to use CMake.
Edit:
Source : http://blog.jetbrains.com/clion/2014/09/clion-answers-frequently-asked-questions/
I am not very familiar with CMake and could not use Mondkin's solution directly.
Here is what I came up with in my CMakeLists.txt using the latest version of CLion (1.2.4) and MinGW on Windows (I guess you will just need to replace all:
g++ mytest.cpp -o bin/mytest by make if you are not using the same setup):
cmake_minimum_required(VERSION 3.3)
project(mytest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_custom_target(mytest ALL COMMAND mingw32-make WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
And the custom Makefile is like this (it is located at the root of my project and generates the executable in a bin directory):
all:
g++ mytest.cpp -o bin/mytest
I am able to build the executable and errors in the log window are clickable.
Hints in the IDE are quite limited through, which is a big limitation compared to pure CMake projects...
I have compiled gdc together with gcc using the android build-gcc.sh script, and have included a new stub in build/core/definitions.mk to deal with D language files as a part of the build process. I know things are compiling OK at this point, but my problem is linking:
When I build a project, I get this error:
ld: crtbegin_so.o: No such file: No such file or directory
This is true for regular c-only projects as well. Now I ran a quick find in my build directory, and found that the file (crtbegin_so.o) does exist within the sysroot I specified when I compiled gcc (or rather, when build-gcc.sh built it).
What are some things I could look for to find a solution to this problem?
Would copying the files locally and linking directly to them be a decent solution in the
interim?
Why would ld (or collect2) be trying to include these for a gdc (D Language) linkage?
The issue arises on NDK r7c for linux as well.
I found that the toolchain ignores the platform location ($NDK_ROOT/platforms/android-8/arch-arm/usr/lib/) and searches for it in the toolchain path, which is incorrect.
However, as the toolchain also searches for the file in the current directory, one solution is to symlink the correct platform crtbegin_so.o and crtend_so.o into the source directory:
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtbegin_so.a
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtend_so.a
Thus your second point should work out (where you can do a symlink, instead of a copy)
NOTE 1:This assumes that the code is being compiled for API8 (Android 2.2) using the NDK. Please alter the path to the correct path as per your requirement.
NOTE 2:Configure flags used:
./configure \
--host=arm-linux-androideabi \
CC=arm-linux-androideabi-gcc \
CPPFLAGS="-I$NDK_ROOT/platforms/android-8/arch-arm/usr/include/" \
CFLAGS="-nostdlib" \
LDFLAGS="-Wl,-rpath-link=$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/ -L$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/" \
LIBS="-lc"
I have found that adding --sysroot=$(SYSROOT) to the compiler options fixes the error:
cannot open crtbegin_so.o: No such file or directory
from my makefile...
CC= $(CROSS_COMPILE)gcc -fvisibility-hidded $(INC) $(LIB) -shared
Note: this assumes that the setenv-android.sh has been run to setup the environment
$. ./setenv-android.sh
In my case quotes were missing from sysroot path.
When I changed
--sysroot=${ANDROID_NDK}\platforms\android-17\arch-arm
to
--sysroot="${ANDROID_NDK}\platforms\android-17\arch-arm"
the project was compiled and linked successfully.
I faced with the same issue in two separate cases:
during building boost for android
during using android-cmake project.
Once I have switched to standalone toolchain issue gone, here is example of command which prepare standalone toolchain
$NDK_ROOT/build/tools/make-standalone-toolchain.sh --platform=android-9 --install-dir=android-toolchain --ndk-dir=$NDK_ROOT --system=darwin-x86_64 --toolchain=arm-linux-androideabi-4.9
Boost specific
for boost you need specify --sysroot several times in your jam
<compileflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm
<linkflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm
For example, if I need Gtk+ include paths.
How to use pkg-config gtk+-2.0 --cflags in Xcode project settings?
One option, but it's not very portable to other developers on the project -- you can just run pkg-config gtk+-2.0 --cflags in your Terminal and paste it into Build Settings -> Other C Flags. I'd be interested to hear how others deal with this in a more portable way though. Ideally, it would be nice to have pkg-config run at compile-time to make building more system-independent.
Create an aggregate target
In Build Phases, add a Run Script
#!/bin/bash
OTHER_CPLUSPLUSFLAGS="$(pkg-config gtk+-2.0 --cflags)"
echo -e "OTHER_CPLUSPLUSFLAGS = \$(inherited) ${OTHER_CPLUSPLUSFLAGS}" > MyApp.xcconfig
In Info in your project, set MyApp.xcconfig as your target configuration file
In Build Phases in your app target, add the aggregate target as a dependency
Exclude MyApp.xcconfig in your version control
One drawback is that until you build the aggregate target directly or indirectly at least once, the autocomplete will not work properly.
More portable would be to write a script that writes the output of pkg-config into an .xcconfig file and then include that in your project. Just be sure to not add it into your source repository.
Use a makefile that uses pkg-config and any other shell tools to build a lib.
Create a small, dependency-free API file for the lib that will compile in XCode, and include it and the built lib in the XCode build.
Optional: encapsulate the makefile build into a "Run Script" build step in XCode.
In addition to #keithyip's great answer, if linker flags are also needed, use
OTHER_LDFLAGS:
#!/bin/sh
OTHER_CPLUSPLUSFLAGS=$(pkg-config --cflags gtk+-2.0)
OTHER_LDFLAGS=$(pkg-config --libs gtk+-2.0)
echo "OTHER_CPLUSPLUSFLAGS = \$(inherited) ${OTHER_CPLUSPLUSFLAGS}" > MyApp.xcconfig
echo "OTHER_LDFLAGS = \$(inherited) ${OTHER_LDFLAGS}" >> MyApp.xcconfig