I am trying to have a scheme with my library that is coherent and usable/reusable.
I work in a team where we work with continuous integration but sometimes I need to use old version of the same library. That's because some part of the software are not updated for using the new version.
I'm actually in the middle of a headache understanding how to use cmake for having something like this:
PATH/Library/Processor/Library_X/Version/static_library_and_includes
Where Library is a common name where to put my stuff
Processor could be attiny24, atmega, lxpXXXX, etc
Library_X is the name of the library
Version a progressive number from 0 to X
static_library_and_includes the static libraries built within that cmake module and the include files needed for using it.
How can I do this using cmake?
I work with different microprocessor crosscompiling with gcc. This is not a problem.
I work with static library, this is not a problem.
I can install them in the right directory. Not a problem
I can't ask the executable to link to the right .a file. Sometimes cmake pick the right one, sometimes not.
Can you please give me a hint on how you guys do it?
thank in advance
Andrea
See the search paths here: https://cmake.org/cmake/help/latest/command/find_package.html#search-procedure .
CMake will find packages in directories named name*, so you can install to <prefix>/FizzBuzz-1.0.0 and <prefix>/FizzBuzz-2.0.0.
As long as each as a correct ConfigVersion.cmake file, it should do what you want.
Related
Firstly, I am not sure if the title exactly words my question well but after three days of searching the web and SO for no working answer, please bear with me.
So the problem is that I have a C application where CMake is the build system. This application relies on libreadline and I can correctly find and link with it using the snippet below:
find_library(READLINE_LIBRARY readline REQUIRED)
target_link_libraries(myExe PRIVATE "${READLINE_LIBRARY}")
The problem is that when I build the application on a system with say for example libreadline.so.8 which is the version 8 and move the application to another system that only has libreadline.so.7 or none available, I'll have to install the missing library before I can run the application. This make for a very bad user experience.
I have tried setting the #rpath before the add_executable and add_library with:
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_RPATH}:$ORIGIN")
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
The problem is that while that correctly sets the #rpath for a shared library which forms part of the project, it doesn't do the same for libreadline. Also even if for any reason I am able to get it to work, I don't know how to get call to find_library return a relocatable library (meaning I can't bet that the libreadline.so.8 was build with -fPIC or not).
Whatever I do, I can't get a local copy of libreadline in my build output directory.
Also note that this problem exists on OSX as well just using the Linux example for simplicity.
On OSX when I inspected the executable with tool -l myExe, I noticed that only the Load Command section for the shared executable which is part of my project correctly uses #rpath while the editline (OSX deadline seems to just be an editline) looks like this:
Load command 14
cmd LC_LOAD_DYLIB
cmdsize 56
name /usr/lib/libedit.3.dylib (offset 24)
Any help will be appreciated. I'm quite stuck. But one thing I'm certain of it that I have seen applications that does this which means it's very possible.
I am using the MinGW-w64 installer found here:
https://mingw-w64.org/doku.php/download/mingw-builds
Installing to a directory creates a folder called mingw32 or mingw64 that contains the compiler. I already know that the additional batch script, HTML link, and uninstall executable in the same directory can be deleted.
The mingw32/64 folder contains these folders:
bin
etc
include
lib
libexec
licenses
opt
share
i686-w64-mingw32 (mingw32) or x86_64-w64-mingw32 (mingw64)
I only wish to compile with C and nothing else. So what files can I delete in order to reduce the file count because the compiler contains files for Ruby, Fortran and other languages which as I stated, I don't need it.
Why are people still using Mingw or Mingw64 instead of TDM-GCC ? You have to rely on the default builds or build it yourself from source. Trying to install it on your own terms sucks.
TDM-GCC on the other hand, you can specify where and which components to install as you wish. You can upgrade or remove it without any worries. It's more fast, easy,modern and equivelant these days.
Now for your question, you can download and install TDM-GCC by it's installer. I don't really think you need any further instructions as a 5 year old would understand how to use it. Just select only the components required for c.
If you don't understand,I would gladly help you more if needed. ^_^
If you want a smaller GCC toolset, try MinGW Distro.
Scroll down to "How To Build Your Own Distro", download components-14.1.7z, extract it, extract binutils 2.27 and GCC 6.3.0 inside the same folder. The total size is about 270MB.
as far as i know the minimum are yours
1, bin
5. libexec
not all tools in bin you may need but generally i would hold both of those dirs
you also ned libraries and headers if you want to build abainst standard c library and windows.h, so
include
lib
is also needed (hovever part of it may contain also headers and libraries for c++ standard library) all those main 3 libs are kinda mixed there afaik so it might be a bit hard to find what comes for what
Basic Question:
How can I get gcc to tell me where it searches for Ada includes?
Specific Problem:
I have just finished converting a C library's header files to Ada specs so that I can interface with the library using Ada. I now want to install the specs on my system. I also want to make the installation portable to some extent so that I can make install on any machine (and thus host the specs and Makefile on Github or similar). I'm just not sure where exactly to install the specs to.
gnat ls -v will give you the default search paths.
If you want to install your own Ada library, you should place a project file (.gpr) in the "Project Search Path", which will tell gnat where to find the ada and ali files and the library.
Normally, you will place the ada files in /usr/[local/]include/myadalib and the ali files in /usr/[local/]lib/myadalib and maybe link the .so file into /usr/[local/]lib, but you can put them anywhere you want. The important thing is to place the project file (myadalib.gpr) in the project search path.
You can even adjust the project search path by setting the ADA_PROJECT_PATH environment variable.
I have to use LU decompostion to fit a simple model to some data (simulated) in C. An example of what I need to do is here:
However, I'm stuck with a more basic problem: how do I install packages in C and call them in my code?
I'm new in C and I'm used to R. But I have this assingment to do some tests about Matrix inversion, LU decomposision and the professor suggested using Lapack to easy things (thus, I don't need to code myself the LU decomposition etc.). But I don't know how to install the package and call it in my code, in order to use the functions of LAPACK.
I have a windows 7 64 bits and I'm using compiler Code Blocks 8.02
Thanks for any help.
Normally you don't "install" C libraries in that sense. Normally, in Windows you have three types of files. The header files, typically ending in .h, the dynamic library, .dll, and most likely some linker files (typically, .lib, .a or something). The linker and compiler will need to be able to find these files somewhere. Normally you set the include directory paths, and library directory paths.
E.g. Let's say you downloaded a library called foo, and you extract it to C:\foo.
In that folder, libfoo.a, foo.dll and foo.h reside. In Code::Blocks you will have to point include directory path to C:\foo and library path to C:\foo so that the linker and compiler know where to look for these files. Since you're linking against the foo library, you will also have to set -lfoo or something similiar in linker command line. This is GCC syntax, but I think Code::Blocks uses GCC compiler behind the scenes anyways.
In the C code you can just #include <foo.h> and the compiler will find it for you.
You need to install that library and it might actually supply a tool for that. Check their documentation (e.g. a file INSTALL or README in their distributed sources). If the library uses only headers you might only need to copy it's headers to some directory on your system, but their buildsystem might be able to do that for you.
Once that is done you would tell your IDE on where to look for the sources and if the library uses not just headers to link against the actual library file. See the documentation in the Code::Blocks Wiki on how this is done for some example cases and adapt for your library.
The simplest thing to do in your situation is to install Cygwin. You can use the setup.exe installer to install the GCC and the LAPACK libraries. When you want to use the LAPACK library, you will add the -llapack option to your GCC command line.
I have a project that links to libssl.so and I'm hitting a bug in libssl and never versions of the lib fixes it. However on the system I'm working I don't have root account so I've built libssl and prerequirements myself under $HOME/opt.
Now, when I'm doing:
./configure --prefix=`$HOME/opt`
make
the build system still uses the older system-wide version of libssl.
I'm trying to find the proper way to "hack" autotools to link with libs I've compiled.
I'm not sure, but perhaps you should also add the new path to the PKG_CONFIG_PATH. That is, if your project uses PKG_CHECK_MODULES for finding libssl.
There's always ./configure LDFLAGS=-L$HOME/opt/lib CPPFLAGS=-I$HOME/opt/include. But that method globally uses headers from that prefix and globally links against libs located there.
Many projects provide AC_ARG_WITHs to allow to customise paths, e.g.
AC_ARG_WITH([ssl], ...)
or
AC_ARG_WITH([ssl-prefix], ...)
AC_ARG_WITH([ssl-libs], ...)
AC_ARG_WITH([ssl-includes], ...)
in analogy to autoconf's --x-includes and --x-libraries
But I guess it's a question of personal taste.
Just noticed you don't want to change your files, in that case you could just add the library in question to the the LIBS variable, or use an rpath:
./configure LIBS="$HOME/opt/lib/libssl.so.x.y.z"
or
./configure LDFLAGS="-Wl,-rpath,$HOME/opt/lib/"
It seems that:
LDFLAGS="-L$HOME/opt/lib" ../configure --prefix="$HOME/opt"
is forcing autotools to try $HOME/opt/lib first. If anybody knows better or more general answer I'm still all ears.