Fedora build issue

[brancomat]

Hi, I'm trying to compile the last freewheeling release on Fedora (by the way: thanks for your work!)

I had a ‘::malloc’ has not been declared error while compiling

c++ is not my cup of tea, but after some googling I found this:
https://nerdland.net/unstumping-the-internet/malloc-has-not-been-declared/

Relevant bit:

When configure tries to test for the presence or GNU-compatibility of malloc and other functions, it compiles a small test program and then tries to run it to see if it works. The problem is that if it fails, configure isn’t smart enough to understand if the reason for failure was related to what it was trying to test or not.

Long story short, the compiling flags to test malloc included a -lSM that was failing on my system since it missed the libSM-devel package.

Even without the malloc test the compilation fails at some point for the missing library, I think it would be better to test the presence of the library in the configure and give some meaningful error if it's missing since it seems a non-optional build dependency.

[brancomat]

Further clarification after a chat with @edigiacomo:
this is not a freewheeling issue, this is a dependency issue internal to the fedora ecosystem.

The AC_PATH_XTRA in the configure.ac triggers the macro in /usr/share/autoconf/autoconf/libs.m4, relevant bit:

AC_CHECK_LIB(ICE, IceConnectionNumber,
[X_PRE_LIBS="$X_PRE_LIBS -lSM -lICE"], , $X_EXTRA_LIBS)

and libSM-devel should be a dependency of libICE-devel but for some reason it isn't.

I'll leave the issue open only because the Fedora dependencies in the wiki page Compiling could be updated to avoid the issue:

 su -c 'dnf install libtool gcc-c++ nettle-devel freetype-devel SDL_gfx-devel   \
                    SDL_ttf-devel liblo-devel jack-audio-connection-kit-devel   \
                    libsndfile-devel libxml2-devel libICE-devel libSM-devel libvorbis-devel

(basically: adding libSM-devel to the list)

Also (very optional):
AC_FUNC_MALLOC could be moved before the AC_PATH_XTRA to avoid adding extra libraries to the test

I don't know if it's useful to anyone, but I ended up with a working fedora specfile for rpm packaging, I'll attach it here.
freewheeling_spec.tar.gz

[bill-auger]

indeed Daniele - i noticed the same things building on the OBS this week - if you are packaging for yourself, you could have used my .spec file, or the binary in the OBS repo; but i did only the minimum to get it to compile - opensuse had no problem with it; but i had to add libsm-devel to the deps list for fedora - thanks for following through so thoroughly, to get to the root of the issue are you packaging freewheeling for the fedora repos? - i am not very familiar with RPM packaging - feel free to scrutinize my .spec file and offer any advice (or show me yours?) https://build.opensuse.org/package/show/home:bill-auger/freewheeling the wiki should be updated at some point, at least to add the OBS repo to it - i will keep an eye on this until then

On Sun, 03 May 2020 09:12:08 -0700 Daniele wrote: and `libSM-devel` should be a dependency of `libICE-devel` but for some reason it isn't.

FWIW, on arch systems, 'libice' is a dependency of 'libsm' - if fedora has reason to see the implication in the other direction, perhaps an argument could be made for having them be mutually dependent

[brancomat]

Thanks, I didn't know there already was a specfile available. I attached my one to my last comment but yours is better since it considers also suse and mageia (my one was focused on fedora).

It would be great to add the packaging files to the repo (or to link them in wiki?)

FWIW, on arch systems, 'libice' is a dependency of 'libsm' - if fedora has reason to see the implication in the other direction, perhaps an argument could be made for having them be mutually dependent

Yes, I got that wrong. In fedora and debian too libICE is a dependency on libSM.
It's the autoconf macro that seems to reason the other way around, checking ICE symbols and taking libSM presence for granted, so I think it may be considered an autoconf bug.

[brancomat]

Some more feedback on your specfile, there's a small error in line 13:
%if 0%{?fedora_version} should be %if 0%{?fedora}

Also, I put up a small repo to distribute rpm packages for freewheeling for fedora and suse (mageia builds failed but it's a distro I honestly never used):
https://copr.fedorainfracloud.org/coprs/dbranchini/freewheeling/

I used your spec as a base, I just bumped it to 0.6.6.
I did it for myself but I could easily mantain it, we could add it to the "OS-Specific-Packages" page of the wiki.

I could help for this and the other trivial wiki edits, if you want.

[bill-auger]

`%if 0%{?fedora_version}` is not an error on OBS - it could be a lagacy things; but it works - the fedora builds would have failed due to missing dependencies otherwise - i think the difference is that %{?fedora_version} is a version number, where `%{?fedora}` is like a boolean - `%{?fedora_version}` can be used to give version constraints like `%if 0%{?fedora_version} < 30` - that is often necessary on OBS because it supports multiple releases of each distro, which can have different requirements or build recipes i did not spend enough time to get mageia packages working - it probably just needs its dependencies fudged a bit - same with some debian and ubuntu versions i am not familiar with fedora-cloud; but presumably, it hosts only RPM repos - OBS does the same, but also arch, debian, and ubuntu repos - it is also automated - you do not need to build anything on your local box, unless it is broken - all packages get built on the server in pristine VMs upstream maintainers should generally not bother with packaging at all - i do it as a convenience to cover distros that do not package it; or in this case, because the debian package is currently buggy - but distro packages are best maintained by someone on the team of that distro - ideally, fedora would pick it up again; and no one would need to maintain a third-party repo - i see them more as a work-around than a proper solution im pretty sure i could add you as a collaborator, if youd like to help maintain the OBS repo - for this project, there is very little to do though - freewheeling is complete, and also (known) bug-free now; so there is barely any need for new development or new releases - once per year or so, i have needed to fix some new compiler warnings - it was written very well, in terms of maintainability - unless SDL1 is dropped from the major distros, freewheeling should keep rocking forever with little attention i probably will put the packaging files in the git repo eventually, on a 'packaging' branch - i have a workflow that i use on other projects, to automate releases and packaging - with that in place, a simple pull request on github for a change to the .spec.in file, would be enough for me to very easily trigger new builds on OBS https://github.com/bill-auger/git-packaging-hooks