I'm working on project, that uses automake&autoconf. Now I need to add a third-party library, that located in subdirectory 'mylib'. That library has it's own 'configure' script and requires speacial flags.
So, my project configure should be used like this way:
./configure --with-aaa=no --enale-bbb=yes --enable-ccc=yes
But the third-party library shoould be configured with another flags:
./configure --enable-ddd=yes
How can I add subdirectory with my library to configure script of my project, but let library to be configured with it's own flags?
I looked through autoconf & automake abilities and found only AC_CONFIG_SUBDIRS(mylib), that will only run ./configure script of library with flags of my project, but that's wrong.
Related
I am trying to build jpeg-9d library from sources on Alpine Linux (3.14.2).
I would like to obtain only static libraries (.a files) from libjpeg.
This is because I would like to get all 3rd party dependencies all-in-one into my application. And this is because I chose Alpine Linux due static musl C library.
The compilation actually was fine, all configure step, make, make install went fine.
./configure --disable-shared
make
make install
But after this I see libjpeg.so file in /usr/local/lib directory.
Actually both libjpeg.a and libjpeg.so are present in /usr/local/lib.
install.txt says that using --disable-shared should be enough.
But it does not work.
I built many 3rd party libraries into static configuration on Alpine Linux;
all of them produced .a files only (of course, I used additional configuration flags),
like zlib, bzip2, xz, zstd, libpng, giflib (small patch was required), expat, freetype2, fontconfig, json, openssl, tiff, boost, etc.
Previously I used libjpeg-6b, and instead of using just make install I used
make install-lib
command and I got only .a files. Old jpeg-6b supported install-lib target. But the new libjpeg-9d does not support this target in make files.
I think it is a bug in jpeg-9d configuration scripts.
Any chance to work-around it or even fix?
Actually --enable-shared=no works fine, no .so files are copied into /usr/local/lib!
So, I can use --enable-shared=no instead of --disable-shared.
./configure --enable-shared=no
make
make install
Maybe it is an issue of automake/autoconf Alpine Linux utilities.
I'm trying to generate the lib files for freeglut library. I've installed cygwin and according to README file that comes with the library,
Building and Installing the Libraries with Cygwin
=================================================
To build "freeglut" under Cygwin, you have two choices:
- You can build a normal Cygwin library, which depends on Cygwin's X11
libraries. To do this, you can just use the normal autotools incantation:
./configure && make install
- Alternatively, you can build a DLL which does not depend on X11 and links
against the opengl32 DLL. To do this, configure need a few more flags:
./configure CPPFLAGS=-mno-cygwin LDFLAGS=-mno-cygwin --without-x && make install
If you don't have MSVC, Open Watcom or Cygwin
=============================================
But If I run ./configure, I got this error
$ ./configure CPPFLAGS=-mno-cygwin LDFLAGS=-mno-cygwin --without-x && make install
-bash: ./configure: No such file or directory
Is there something I need to install in order to solve this issue? The contents of the folder doesn't have configure. These are the files in the folder
If you need freeglut, you need to install the cygwin package libglut-devel
Looking inside setup.ini you will find its description:
libglut-devel
sdesc: "OpenGL Utility Toolkit library"
ldesc: "freeglut
is a completely OpenSourced alternative to the OpenGL Utility Toolkit
(GLUT) library. GLUT was originally written by Mark Kilgard to support
the sample programs in the second edition OpenGL 'RedBook'. Since
then, GLUT has been used in a wide variety of practical applications
because it is simple, widely available and highly portable. GLUT (and
hence freeglut) allows the user to create and manage windows
containing OpenGL contexts on a wide range of platforms and also read
the mouse, keyboard and joystick functions."
category: X11
I am trying to build Guile 1.8.8 from source. I am stuck at the point where the build system is looking for libtool. I have installed it in a non-standard location.
I have already built Guile 2.0.11. In 2.0.11 build system, there is an explicit flag to configure --with-libltdl-prefix, which I think tells the build system where libtool is installed.
For Guile 1.8.8, I have Libtool installed in a non-standard location. How do I tell the build system where it is installed?
I am specifically getting error messages like:
libguile/Makefile.am:40: Libtool library used but `LIBTOOL' is undefined
libguile/Makefile.am:40: The usual way to define `LIBTOOL' is to add `LT_INIT'
I think in general this is a question regarding one or more of the autotools and how the build system finds programs / headers / libraries in non-standard locations.
This link is informative: How to point autoconf/automake to non-standard packages
Find the directory where *.m4 exists, which corresponds to libtool, or package which is in non-standard location.
export ACLOCAL_PATH=/path/to/m4/file
cd /path/to/configure.[in,ac]
autoreconf -if
./configure
Generally to install a package on a linux-based operating system you use
./configure
make
make install
How does this work? And how do I create a package that can be installed this way?
My application uses the Qt framework and I think I'm aiming for something like "MyPackage.tar.gz"
You can create a debian package from your projects. As I understood you want to create a package intended for distibution so I would suggest creating a debian package from your project. Here is an introduction for Debian Packaging system. In the article they at some point describe how to create a "rules" file which is at the core of the build process. Here is a sample of it that I typically use for my Qt/KDE projects:
#!/usr/bin/make -f
#export DH_VERBOSE=1
# This is the debhelper compatability version to use.
#export DH_COMPAT=3
DESTDIR=$(CURDIR)/debian/project
TR_DIR=$(CURDIR)/debian/project/usr/share/qt4/translations
configure:
qmake project.pro
clean:
dh_testdir
dh_testroot
dh_clean
build: configure
dh_testdir
lrelease translations/project_en.ts
$(MAKE)
install: build
mkdir -p $(TR_DIR)
cp translations/project_en.qm $(TR_DIR)
$(MAKE) INSTALL_ROOT=$(CURDIR)/debian/project install
dh_installdirs
binary-arch: build install
dh_testdir
dh_testroot
dh_installmenu
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
This is normally sufficent for small projects.
configure is usually part of GNU build system (autotools), which is not in use in a typical Qt project. qmake is used instead for build file generation and it internally handles most of the tasks configure does for non-qt projects.
The typical build install process for a Qt application is
qmake
make
make install
You could create a simple ./configure script that calls qmake if you need the command names to be identical. You can also use autotools with Qt if you need it, see e.g. Qt Creator Instructions For Autotools
Qt is often used with CMake, which I highly recommend. One notable point is that it likes out-of-source-builds.
Your configure script could be
#!/bin/bash
(mkdir build; cd build; ccmake ..)
and the makefile could be
#!/bin/bash
(cd build; make)
Newer versions of debhelper support qmake. A rules file like,
#!/usr/bin/make -f
%:
dh $# --buildsystem=qmake
Is all that is needed. You need,
bar.file = foo
bar.path = install/dir
INSTALLS += bar
Inside your projects 'pro' or qmake file. qmake will create install targets and the perl file /usr/share/perl5/Debian/Debhelper/Buildsystem/qmake.pm will get called and parse the qmake file. You need to create 'debian/' files, changelog, compat, control, copyright as well the rules file.
I have a c++ project (g++/raw Makefile) designed for linux, I used to statically link everything which worked fine for ages. Now I want to build binaries both statically and dynamically linked. The following command is used in my Makefile to build the dynamic library (say libtest):
$(CXX) -shared -Wl,-soname,libtest.so.1 -o libtest.so.1.0.0 $(LIBTEST_OBJS)
The output is libtest.so.1.0.0 which has the so name libtest.so.1
I found at least a symbolic link libtest.so --> libtest.so.1.0.0 is required to link my client program that actually use the above generated libtest.so.1.0.0 library.
Here my question is if I want to build my software, what is the standard way of managing the above symbolic link? Clearly I don't want this extra stuff in my source directory, but it is required to build my client binary, shall I create it as a temp link for building the client then just remove it when done? or shall I create a directory to host the generate .so library and its links and leave everything there until I do "make install" to install them into other specified directories? Will be cool to now what is the standard way of doing this.
Or maybe the way how I generate libraries is incorrect? shall I just generate libtest.so (as actual library, not a link) to link my executable, then rename the library and create those links when doing ``make install''?
any input will be appreciated. :)
Certainly don't generate libtest.so as an actual link. Typically installing the shared library development files installs the .h files and creates a symbolic link libtest.so as part of some install script you have to write.
If you're not installing the development files, but only using the library in your build process of your binary, you just create the symbolik link from your makefile.
There's not that much of a standard here, some prefer to build artifacts to a separate build directory,
some don't care if it's built in the source directory. I'd build to a separate directory though, and keep the source directory clean of any .o/.so/executable files.
You might find useful information here
My suggestion is to use libtool which handles situations like this.