The standard ones, like AC_PROG_AWK. I looked in the docs, but couldn't find them.
Any help or link would be truly appreciated!
I'm no expert when it comes to automake/autoconf. Yet, a bit of googling revealed this which seems to contain the macro sources: autoconf.git/lib/autoconf.
Automake macros starts with AM_. The AC_ prefix in your example means Autoconf. You should therefore look into the Autoconf manual.
Most of the autoconf macros are stored in $prefix/share/autoconf (where prefix is the prefix used to install autoconf.) In particular, the definition of AC_PROG_AWK can be found in:
$(dirname $( which autoconf ))/../share/autoconf/autoconf/programs.m4
(This is valid for autoconf 2.65, and probably for many version preceding it.)
Related
I found a package on github (https://github.com/okbob/ncurses-st-menu) and am having trouble compile it for BSD platforms like NetBSD or OpenBSD. The instructions say to do ./autogen.sh, ./configure, and then make. So I install the autoconf, autotools, libtool, gettext, and any other necessary packages and run ./autogen.sh. It works without spitting out any errors. But ./configure says it doesn't support "OS x86_64-unknown-netbsd9.0" if for example on NetBSD. Can someone else try to compile this program? Because if this was done by autotools, it certainly should support any of the four major BSD operating systems.
I created a port for FreeBSD here, maybe it will help you get it running on NetBSD. The most important part is the removal of the AC_MSG_ERROR(["OS $host_os is not supported"]) line from tools/ax_pdcurses.m4, then touching config.make, calling autogen.sh to re-generate the configure script. It's also important to set CFLAGS properly and have the appropriate dependencies installed. Also, I used gmake rather than patch the Makefile since I didn't feel motivated to fix it completely.
I don't know the autogen/config tools,
but if you look the configure file:
https://github.com/okbob/ncurses-st-menu/blob/master/configure
lines 4245-4269 only checks for linux,cygwin,mingw.
For other OS gives the error: OS $host_os is not supported
I mean, those C or C++ projects that you build from source on Linux and UNIX systems, usually by issuing those commands:
./configure
make
sudo make install
And they also have files like ./configure, ./configure.ac, ./configure.in at the top directory.
I've heard them variously called autotools projects, or autoconf projects, or automake projects, but I'm not sure which name is the correct one. Is there even a consensus on what they should be called?
Autoconf and automake are collectively called the GNU autotools (and libtool may be included in that category as well), so autotools is the most general name.
Note that not all programs that have a configure script to generate a makefile are necessarily using the autotools, or not all of them.
According to GNU it's officially called the GNU Build System, which is where you find it on Wikipedia. But most people (er, almost everyone?) calls it "the GNU autotools" or "autotools". As stated by #larsmans and others in his answer, none of these tools are required. To quote the last paragraph of the link:
The Autotools are tools that will create a GNU Build System for your package. Autoconf mostly focuses on configure and Automake on Makefiles. It is entirely possible to create a GNU Build System without the help of these tools....
The first page of the autoconf info page refers to the packages as "autoconfiscated".
The other day I came across a linux command that let me see where a program is expecting to find its libraries. It is very useful to solve library dependency problems for not so popular or proprietary software. I used ldd, it was very informative, but missed one crucial piece of information for me:
ldd -v ./my_executable
gave good information for libraries that my_executable can link to.
But for those it can not link/find, ldd only gave information like:
<a_library_name.so.version> => not found
What I want is, instead of "not found", I want to see
not found at /path/to/<a_library_name.so.version>.
on linux you can use the LD_DEBUG. This link is helpful.
Probably you need the strace command
Take a look here http://www.thegeekstuff.com/2011/11/strace-examples/
The information about library paths is stored in /etc/ld.so.conf:
/usr/local/lib64
/usr/local/lib
include /etc/ld.so.conf.d/*.conf
# /lib64, /lib, /usr/lib64 and /usr/lib gets added
# automatically by ldconfig after parsing this file.
# So, they do not need to be listed.
See man ldconfig for more information.
I have an old executable that's scheduled for the scrap heap, but it's not there yet. It relies on some libs that have been removed from my environment, but I have some stub libs someplace where it works fine. Id like to point this executable to these stub libs. Yes, i could set LD_LIBRARY_PATH, but this executable is called from many scripts, and many users and I'd love to fix it in one spot.
I don't have source for this, and would be hard to get it. I was thinking - can I edit this file, using an ELF aware editor, and add a simple PATH to rpath to have it hit the new libs? Is this possible, or once you create an ELF binary, you fix things to locations and they can't be moved?
There is a more universal tool than chrpath called patchelf. It was originally created for use in making packages for Nix and NixOS (packaging system and a GNU/Linux distribution).
In case there is no rpath in a binary (here called rdsamp), chrpath fails:
chrpath -r '$ORIGIN/../lib64' rdsamp
rdsamp: no rpath or runpath tag found.
On the other hand,
patchelf --set-rpath '$ORIGIN/../lib64' rdsamp
succeeds just fine.
There is a tool called chrpath which can do this - it's probably available in your distribution's packages.
Just like #user7610 said, the right way to go is the patchelf tool.
But, I feel that I can give a more comprehensive answer, covering all the commands one needs to do exactly that.
For a comprehensive article on the subject, click here
First of all, many developers talk about RPATH, but they actually mean RUNPATH. These are two different optional dynamic sections, and the loader handles them very differently. You can read more about the difference between them in the link I mentioned before.
For now, just remember:
If RUNPATH is set, RPATH is ignored
RPATH is deprecated and should be avoided
RUNPATH is preferred because it can be overridden by LD_LIBRARY_PATH
See the current R[UN]PATH
readelf -d <path-to-elf> | egrep "RPATH|RUNPATH"
Clear the R[UN]PATH
patchelf --remove-rpath <path-to-elf>
Notes:
Removes both RPATH and RUNPATH
Add values to R[UN]PATH
patchelf [--force-rpath] --set-rpath "<desired-rpath>" <path-to-elf>
Notes:
<desired-path> is a colon separated directories list, e.g: /my/libs:/my/other/libs
If you specify --force-rpath, sets RPATH, otherwise sets RUNPATH
This worked for me, replacing XORIGIN with $ORIGIN.
chrpath -r '\$\ORIGIN/../lib64' httpd
I experienced a (for me) strange behaviour today: Using QMake with the PkgConfig-options etc. I was able to link the opencv libraries, but then I switched to CMake using PkgConfig. Once I tried to build my software, the linker complained that it was not able to find the library libcvaux, which pkg-config returns asked to deliver the libraries for opencv (pkg-config --libs opencv).
In /usr/lib I found a libcvaux.so.{version}, but no "plain" entry libcvaux.so. So what I did was to create a symlink, and now it works.
Now I wonder why it worked before. Is there something to pass ld an option saying "use the newest version, and you get the version by looking at the numbers behind the so suffix"? Or is it more some kind of bug that the maintainers of the opencv package forgot to add this symlink? Because e.g. libcv or libhighgui have such symbolic links.
Thank you!
From the ldconfig manpage:
ldconfig checks the header and file
names of the libraries it encounters
when determining which versions should
have their links updated.
Maybe an earlier ldconfig run deleted the link.