| View previous topic :: View next topic |
| Author |
Message |
erg_samowzbudnik
Apprentice
Joined: 09 Sep 2011
Posts: 211
Location: European sticks
|
 Posted: Mon Feb 12, 2024 10:00 am Post subject: collectd build fails (GNU autotools configuration issue?) |
 |
|
Hi All.
I have a problem building collectd-5.5.0 with patches. It is old version.
I have to stick to this old version as well as the old version of the system I use.
I'm building it on Centos 6. Since I'm using GNU autotools I think it does not matter that much and you guys can help me out to debug this issue.
Let me describe the problem:
I can build collectd itself without an issue.
Problem appears when I add patches.
The first issue was the old version of aclocal - I had version 1.11 installed, configure politely told me to upgrade automake to version 1.14 - solved that particular issue.
In order to install automake-1.14 I had to get autoconf-2.65 or newer, so I switched to autoconf-2.69e.
So far so good.
Now I have an issue I don't really know what to do with. Configure fails with this error:
| Code: | checking for swapctl... no
checking whether NAN is defined by default... yes
checking if doubles are stored in x86 representation... ./configure: line 19901: ac_fn_c_try_run: command not found
no
checking if endianflip converts to x86 representation... ./configure: line 19989: ac_fn_c_try_run: command not found
no
checking if intswap converts to x86 representation... ./configure: line 20071: ac_fn_c_try_run: command not found
no
configure: error: Didn't find out how doubles are stored in memory. Sorry.
make: *** [config.status] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.Pm6rpX (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.Pm6rpX (%build) |
Here is the link to the failed build log:
https://pastebin.com/sR4sQyX5
Any tips and clues would be much appreciated. |
|
| Back to top |
|
 |
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1541
Location: South America
|
| Posted: Mon Feb 12, 2024 5:09 pm Post subject: Re: collectd build fails |
|
|
| erg_samowzbudnik wrote: | I can build collectd itself without an issue.
Problem appears when I add patches.
The first issue was the old version of aclocal - I had version 1.11 installed, configure politely told me to upgrade automake to version 1.14 - solved that particular issue.
In order to install automake-1.14 I had to get autoconf-2.65 or newer, so I switched to autoconf-2.69e.
[...]
Now I have an issue I don't really know what to do with. Configure fails with this error:
| Code: | ...
checking if doubles are stored in x86 representation... ./configure: line 19901: ac_fn_c_try_run: command not found
no
checking if endianflip converts to x86 representation... ./configure: line 19989: ac_fn_c_try_run: command not found
no
checking if intswap converts to x86 representation... ./configure: line 20071: ac_fn_c_try_run: command not found
no
... |
|
You say you added patches. Since you mention autoconf and automake, I suppose that one or more of the patches modifies collectd's configure.ac (or configure.in) file. It is possible that at least one of them is not correct, or there was some error in the procedure for generating the updated configure script. That is usually done with autoreconf.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
erg_samowzbudnik
Apprentice
Joined: 09 Sep 2011
Posts: 211
Location: European sticks
|
| Posted: Tue Feb 13, 2024 8:36 am Post subject: |
|
|
Suppose I should have mentioned it rather than leaving it for you to figure out - you are indeed correct, one of the patches modifies configure.ac.
This is getting strange. I know (because we use it) that this has compiled in the past.
I'm trying to follow the breadcrumbs. There's a part of configure which fails with:
| Code: | checking if doubles are stored in x86 representation... ./configure: line 666: ac_fn_c_try_run: command not found
no
checking if endianflip converts to x86 representation... ./configure: line 1666: ac_fn_c_try_run: command not found
no
checking if intswap converts to x86 representation... ./configure: line 2666: ac_fn_c_try_run: command not found
no
configure: error: Didn't find out how doubles are stored in memory. Sorry.
make: *** [config.status] Error 1
|
This is weird. Function ac_fn_c_try_run is there.
Checking those endianflip/intswap is supposedly done only while crosscompiling
The part of code that is just under that code (not sure this fails or the code under) does something like:
| Code: |
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
< some C++ code here >
_ACEOF
|
Now if I take that C++ code and try to compile it on it's own, compilation fails with:
| Quote: |
error: 'uint64_t' undeclared (first use in this function)
|
more errors follow
I'm using gcc-4.4.7 here.
From cppreference I see that uint64_t type is 'provided if and only if the implementation supports the type'
I feel dumb, not a C guy: what am I dealing with here?
It look like (to me):
1.) A test fails and configure decides we're crosscompiling,
2.) C++ code should contain makro UINT64_MAX after '#include <stdint.h>' but doesn't
Or am I looking at it the wrong way? |
|
| Back to top |
|
|
erg_samowzbudnik
Apprentice
Joined: 09 Sep 2011
Posts: 211
Location: European sticks
|
| Posted: Tue Feb 13, 2024 9:32 am Post subject: |
|
|
I have found another curiosity.
I run shellcheck on configure patched (or should I say 'generated'?) with configure.ac and it fails with:
| Code: |
PKG_CHECK_MODULES(LIBNOTIFY, libnotify,
with_libnotify="yes",
if test "x$LIBNOTIFY_PKG_ERRORS" = "x"; then
(...)
|
| Quote: |
SC1036: '(' is invalid here. Did you forget to escape it?
|
Corresponding snippet from configure.ac:
| Code: |
PKG_CHECK_MODULES([LIBNOTIFY], [libnotify],
[with_libnotify="yes"],
[if test "x$LIBNOTIFY_PKG_ERRORS" = "x"; then
(...)[/quote]
|
|
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1541
Location: South America
|
| Posted: Tue Feb 13, 2024 2:43 pm Post subject: |
|
|
Based on the error messages about the missing ac_fn_c_try_run, I think that the immediate problem is that at least one of the patches is making autoconf 2.69e generate a malformed configure script, so probably more related to your last post. Bad M4 quoting —which is hard to get right— can do that, for example. There is not enough information to know what's wrong, though.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21644
|
| Posted: Tue Feb 13, 2024 3:59 pm Post subject: |
|
|
| Since you cannot upgrade to a recent version of collectd, perhaps you should avoid patching the old configure script at all, so that you do not need to regenerate configure. What are you trying to do that you are patching collectd? Can you share the specific patches? |
|
| Back to top |
|
|
erg_samowzbudnik
Apprentice
Joined: 09 Sep 2011
Posts: 211
Location: European sticks
|
| Posted: Wed Feb 14, 2024 9:04 am Post subject: |
|
|
GDH-gentoo: I did suspect this, I looked really hard at the configure script and a patch for it but couldn't see the issue. So I took all those patches and built the same version of collectd with them on a Centos 8 (with autoconf-2.69 - the same version as on Centos 6, and automake-1.16 - on Centos 6 it was automake-1.14, and m4-1.4.18 - on Centos 6 it was m4-1.4.18b). I missed a lot of dependencies and so it didn't build, but configure phase did not fall over. Would that suggest that it's a bug in autoconf?
I am not fully aware of what is involved in generating configure script beyond autoconf and m4 - are there other packages involved?
I will try now to build on Centos 6 with automake-1.16
HU: Unfortunately, I cannot share those patches. But to answer indirectly:
Patch for configure.ac only adds this custom plugin and dependency on libnotify for this plugin.
Patch for configure is more involved, checks if custom plugin is enabled and if so checks for libnotify presence. Then it inserts '#define HAVE_PLUGIN_DUMMY_PLUGIN 1' into confdefs.h. Then it does one more test if either of BUILD_PLUGIN_DUMMY_PLUGIN_{TRUE,FALSE} is defined to throw an error if not.
Here's generated configure script - in three parts as it was too large:
http://pastes.io/kaysdciqnq
http://pastes.io/rfj65j40mm
http://pastes.io/olvkokfxee
Thanks for looking into this. It is a right pickle.
Edit: on Centos 8 generated configure script does not contain the malformed part i.e. PKG_CHECK_MODULES |
|
| Back to top |
|
|
erg_samowzbudnik
Apprentice
Joined: 09 Sep 2011
Posts: 211
Location: European sticks
|
| Posted: Wed Feb 14, 2024 9:19 am Post subject: |
|
|
I have tried now with automake-1.16 and automake-1.19 and I do get the malformed part in generated configure.
So a build on different OS version, with the same versions of packages used to generate 'configure' script fails on one and not on the other.
The picture I have is incomplete I suppose. I have assumed so far that moving parts here are:
- automake
- m4
- package sources
- patches
But there seems to be a mystery wrench in the cogs.
I'm off to read about autotools in detail. |
|
| Back to top |
|
|
erg_samowzbudnik
Apprentice
Joined: 09 Sep 2011
Posts: 211
Location: European sticks
|
| Posted: Wed Feb 14, 2024 12:15 pm Post subject: |
|
|
Solved by going back to the automake-1.11 and regenerating Make files with
| Code: |
autoreconf --force --install
|
configure script gets generated, there are compile errors coming from changes in the diff files (how the f***k was it built successfully previously?!? We'll never know. Guy that did it left company years ago) so we fix them diffs, compile again and Bob's your uncle.
I lost over a week of my life in that geriatrics department. What did I learn from this?
This my life now. How did I get here?
This really was a warning, not a joke. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1541
Location: South America
|
| Posted: Wed Feb 14, 2024 12:39 pm Post subject: |
|
|
| erg_samowzbudnik wrote: | | What did I learn from this? |
The meaning of "bitrot"? 
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21644
|
| Posted: Wed Feb 14, 2024 1:34 pm Post subject: |
|
|
| erg_samowzbudnik wrote: | | I lost over a week of my life in that geriatrics department. What did I learn from this? |
Don't mix old code with new systems. If you need to support an ancient system, keep an ancient development environment around for it. If you want to build on a recent system, use code that was updated upstream to work on that system. |
|
| Back to top |
|
|
|
Other Things Gentoo
