#autoconf — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #autoconf, aggregated by home.social.
-
Let's find out how to get predictable IPv6 addresses assigned to OpenBSD VMs https://undeadly.org/cgi?action=article;sid=20260512115225 #openbsd #networking #ipv6 #predictable #dynamic #autoconf #development #freesoftware #libresoftware
-
The March #GNU Spotlight by Amin Bandali is now available! Read it here: https://www.fsf.org/blogs/community/2026-march-gnu-spotlight #FSF #PSPP #Autoconf
-
Weird. Opening a
configure.amfile in #NeoVim makes the autotools-language-server lock up and use an entire core.Anyone else noticing this in their projects?
If it matters, the project is plptools.
-
I have started migrating macros from the Sorts Mill Autoconf Archive to a new archive, with improvements: https://github.com/chemoelectric/chemoelectric-autoconf-archive
Mostly the improvements are making the cache variables not have names that start with things like ‘________ac’.
-
When building alsa-utils with a custom toolchain + sysroot, I get this error:
libtool: error: cannot find the library '/usr/lib/libasound.la' or unhandled argument '/usr/lib/libasound.la'
However, the file does exist inside of the sysroot, and configure claims to use the sysroot that the compiler specifies.
How do I solve this?
-
LibMPU (создание проектов)
В предыдущей статье мы сделали краткий обзор возможностей библиотеки функций для работы с большими числами. В приведенных примерах, для автоматического задания флагов компилятора и компоновщика, мы рассмотрели использование скрипта mpu-config . Данный скрипт поставляется во время инсталляции LibMPU и позволяет упростить написание Make-файлов для программ, использующих библиотеку LibMPU . Однако это не единственный вариант составления Make-файлов с использованием данной библиотеки. В данной статье мы рассмотрим применение GNU Autotools , которые позволяют обеспечить переносимость программ и упростить создание сложных проектов. После инсталляции LibMPU на вашу GNU/Linux систему в распоряжении пользователя, помимо самой библиотеки, будет находиться m4-скрипт /usr/share/aclocal/libmpu.m4. Скрипт l ibmpu.m4 предназначен для использования в проектах, создаваемых с помошью утилит Autoconf , Automake .
https://habr.com/ru/articles/872332/
#gnu #autotools #autoconf #Automake #configure #длинная_арифметика #большие_числа
-
#foss enthusiasts… Fancy a #gnu #autoconf #automake and #libtool #book? Swing by Hammersmith area and it’s yours. #macos #bsd #devops #books #development #developers #programming #oss #opensource #unix #linux
-
#autodafe 1.1 has been released (#autotools / #autoconf) https://gitlab.com/esr/autodafe
-
Sure, but #Windows is still an Achilles Heal for the #AutoTools, unless you use #MinGW & #MSYS:
“What Autoconf Got Right”, Leah Neukirchen (https://leahneukirchen.org/blog/archive/2024/04/what-autoconf-got-right.html).
Via HN: https://news.ycombinator.com/item?id=40544336
On Lobsters: https://lobste.rs/s/ebnqzl/what_autoconf_got_right
-
#GCC14 promoted some warnings to errors. This can break #autoconf, #CMake, #Meson or other build environments autoprobing for features, resulting in code built with missing or altered functionality. This could even lead to security impact, if some security related feature is unexpectedly not enabled.
Passing CC as "gcc -fpermissive" should fix this. If this is not an option there's even the nuclear option of adding a gcc wrapper script that does:
#!/bin/sh
exec /usr/bin/gcc -fpermissive "$@"EDIT: I do not mean to say that these new options should blanket-disabled globally. There however are currently some packages that have problems with GCC 14 (missing features or existing functions not being used, or just failing to build). Naturally these packages should be fixed themselves. Meanwhile -fpermissive will allow building most of these troublesome packages.
-
"If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
-
Regarding the #xz backdoor Jonathan Corbet from https://lwn.net/ thinks that #autoconf is part of the problem: "Why are we still using ancient build systems that almost nobody understands?"
So do I. I have not been using #sendmail for decades which used to have the same #m4 bullshit. -
It's late enough to be hacker hours, if you're as old as I am. Gonna write down a bunch of rambly thoughts about #xz and #autoconf and capital-F Free Software sustainability and all that jazz. Plan is to edit it into a Proper Blog Post™ tomorrow. Rest of the thread will be unlisted but boosts and responses are encouraged.
-
Poll for the #autoconf haters:
You get to send *one* of the implementation languages to the cornfield. Which do you want gone more?
-
@manx @jeang3nie @kornel Oh, I'm sure #autoconf will go away, as fewer and fewer people understand it, but so far what I've seen, "they are going to reinvent autoconf poorly".
I'm quite partial to the suite (as a dinosaur for sure), despite its opaque architecture mixing sh and m4. Maybe 10% of it is never needed anymore, but the rest still has its purpose.
Even for giflib, ESR himself keeps bolting back old functionality after "abolishing" autoconf.
https://sourceforge.net/p/giflib/code/ci/8bed392c280ad2c237e8bf1beca6f8f68f893e87/log/?path=/Makefile -
I'm old enough to have begun using #unix before #linux, and in the first years, I used *nix (well, SunOS, Solaris, and Digital OSF/1, to say more precisely) for so long. I'm what nowadays is considered a Veteran Unix Admin or #vua. I'm still curious enough to stay updated about current tech, but I wonder how many people out there in the #fediverse are still passionate about tech novelties but even cultivate legacy knowledge such as #C, #Perl, #Tcl, #autoconf and #automake, #m4 and above all why?
-
Today's bug is an `autoconf-2.72` bug: https://savannah.gnu.org/support/index.php?110990
There `autoconf` generates invalid shell code for the following:
AS_IF([test "x$enable_termcap" = "xyes"],
AC_CHECK_LIB(terminfo, tgetent, , [
AC_CHECK_LIB(termcap, tgetent, , [
...and complains as:
./configure: line 3476: syntax error near unexpected token `;;'
./configure: line 3476: ` ;;'At least that happens on `editline-1.17.1`. I'm not sure if it's a valid `configure.ac` syntax.
-
I've just posted a release candidate for #GNU #Autoconf 2.72. Please spread the word and test it as thoroughly as possible **in the next 48 hours**. If I don't hear about any show-stopper bugs I intend to make the final release at about this time on Friday, Dec. 22, 2023.
If I *do* hear about show-stopper bugs, the release is going to be pushed back until end of January 2024 at the earliest because I'll be on vacation for the next three weeks.
https://lists.gnu.org/archive/html/autotools-announce/2023-12/msg00002.html
-
today's #autoconf rathole started out at https://savannah.gnu.org/support/?110872 and ended up at https://stackoverflow.com/questions/77668466
if you have ever wondered why autoconf development proceeds so slowly -- this is an absolutely typical experience.
-
just #autoconf things: "Gee, I wonder if there's a way to inject significant delays into every invocation of mkdir(2) for one particular process ... using only the capabilities of /bin/sh and associated utilities, as they were in 1993, without compiling any C, without assuming a particular operating or file system, without assuming any third-party software has been installed yet, and without knowing whether the program loaded into that process is dynamically linked, or, indeed, whether dynamic libraries even exist."
-
#gnu #autoconf / #automake tipp:
# tar-ustar: use ustar format of tar (POSIX 1003.1-1988) to lift the
# 99 character limit on filenames (it is now 155 for the directory and
# 256-dir for the file). Needs Automake 1.9 or newer
# see https://www.gnu.org/software/automake/manual/1.10/html_node/Options.html#index-Option_002c-tar_002dv7
# and https://www.gnu.org/software/tar/manual/html_node/Formats.html#Formats
AM_INIT_AUTOMAKE([1.9 tar-ustar])(this is planned to become a default in make dist—the limit is there to support some really old tar implementations—but currently the default is still tar-v7 with max 99 chars)
