Wiki » Autobuild errors

The Autobuild results page highlights certain common errors encountered in the build in the Detected errors column. Usually, these result from new compiler versions or additional build-time checks that affect many packages and therefore make them worthwhile to highlight. This page gives information on the detected problems and hints about how to fix them. New checks may be added in bugscan.rb

conflictstrl

Problem: A function declaration for strlcpy or strlcat has been found that conflicts with the ones provided by glibc. These functions (which are widely used but left out of glibc, meaning programs needed to provide their own implementations) were finally added in glibc 2.38. The application's implementation has a differing definition, likely minor but enough to cause an error.

Solution: Patch the source to eliminate the home-grown strlcpy/strlcat functions and use the optimized glibc versions instead. This assumes that the home-grown ones are compatible with the standard glibc/OpenBSD versions. There is likely already a #ifdef or similar conditional in the code so they will be skipped when being compiled on OpenBSD (& others that provide the functions natively), so extend this check to include glibc >= 2.38 (e.g. with #if !__GLIBC_PREREQ(2,38)).

More info: https://news.ycombinator.com/item?id=36765747

Added for mga10.

debuglist

Added for mga6.

depcomp

Added for mga6.

dynamicexception

Problem: The C++ code uses dynamic exception specifications, which is a language feature removed in C++17.

Solution: Look for an upstream patch that stops relying on this feature. Or, compile the code as C++14 by adding the gcc command-line parameter -std=c++14 (or -std=gnu++14 if GNU language extensions are needed) to CXXFLAGS.

Added for mga9.

egginfomissing

Problem: The problem is due to an incompatible change in python3-setuptools.

Solution: If an existing package build fails because of missing .egg-info an/or the build tries to install .egg, the fix ATM is to add 'export SETUPTOOLS_USE_DISTUTILS=stdlib' in %install.

Added for mga9.

findlang

Added for mga6.

fortranscalarandrank

Added for mga8.

implicitdecl

Problem: A function is being used that has not been declared in an #include file. glibc 2.39 changed its header files so headers that used to be implicitly included in a program by other headers no longer are.

Solution: Patch the source to #include the right standard header file. It's probably an obvious one like #include <stdlib.h> or #include <string.h>.

Added for mga10.

incompatibleptr

Problem: A function is being passed in a value that doesn't match the type in the function prototype.

Solution: If it is a function pointer being called that does not have a full prototype, gcc >= 15 assumes arguments are int, whereas previous versions did not check the type of arguments in this case. If lacking a full prototype is the problem and there is no function prototype, add one in an appropriate .h file (or make the partial prototype complete). If compiling a library, make sure that a new prototype doesn't affect backwards compatibility with older applications using the library. If it's not possible to add a prototype, you can add the -std=gnu17 compiler option (e.g. by appending to CFLAGS before the build step) to revert to the old behaviour (but don't do this to fix a library because it means that all applications using the library will also need to add the flag). If there is a prototype but it does not match the number of arguments passed in, then it is a compatibility break, likely with some dependent library, and the application will need to be patched to use the correct arguments.

Added for mga10.

javacmissing

Added for mga6.

javadep

Added for mga8.

libtool

Added for mga8.

literalformat

Problem: A call to printf (or similar) uses a variable as the format string (and no other arguments), which is a potential security risk. This suddenly caused warnings in many curses-based programs when an ncurses update started allowing gcc to warn on its printf-like functions (like mvwprintw).

Solution: Patch the program to replace the format string variable with the literal "%s" and use the variable itself as the next argument.

Added for mga9.

maven

Added for mga6.

mountcompat

Problem: glibc 2.36 introduced an incompatibility in its header files so that <linux/mount.h> and <sys/mount.h> cannot both be #included at the same time. Sometimes, one of the headers is included transitively so it isn't obvious in the application.

Solution: The two headers provide two different ABIs, and it's considered bad practice for applications to #include <linux/*> headers when a libc equivalent is available. The application should be patched to use the glibc ABI available in <sys/mount.h>. See the glibc release notes.

Added for mga9.

multipledefinition

Problem: The C/C++ program has defined the same symbol is two or more object files. This is usually because a global variable or function is defined in a header file that is included from at least two different source files.

Solution: If the problem is due to multiple global variable definitions, patch the source code so the header file defines the variables as extern and only one source code defines them without extern. If the problem is due to multiple function definitions, patch the source code so that the functions are defined as inline in the header file, or define them in one location and change the header file to only include a function prototype.

Added for mga8.

ocamlunsafestring

Added for mga8.

oldautoconf

Added for mga6.

packagedfilemissing

Problem: The spec file says to package a file in its %files section that does not exist.

Solution: Find out why the given file is not available. It might be that a new version of the application has dropped the file, moved it to another location, renamed it or stopped installing it. Either fix the %files section to match, or fix the build so the file is installed in the expected location, as appropriate.

Added for mga6.

python3

Problem: The program is written for Python 2 but Mageia only supports Python 3.

Solution: Fix the program to use Python 3 or drop it from Mageia. Look for a Python 3 patch upstream, or (if the program is simple), try automatically converting it to Python 3 using 2to3. If the latter, test the result thoroughly that it actually works, as 2to3 cannot properly convert all Python 2 programs.

Added for mga8.

rpath

Problem: The post-build RPM helper script check-rpaths has detected a problem with the RPATH used during a build. The specific problem file(s) are listed with the specific error shown as a bitmask that you can decode using the key shown immediately above in the log. RPATH is a feature of the run-time linker to specify where a dynamic library is located. Usually, dynamic libraries are in the standard locations /usr/lib or /usr/lib64 and don't need an explicit RPATH, but if they're in a special location (like /usr/lib64/someprogram-plugins/) the application may need an RPATH to find those libraries at run-time.

Solution: The RPATH is usually set in the configure script or makefile with a command-line option like -Wl,-rpath -Wl,/some/bad/path. If the bad path is bad because it's blank, it duplicates a standard library location (like /usr/lib64), or it points to an invalid location, then just remove it (which might take a patch, setting an environment variable or changing a configure argument). If it's due to another issue, then figure out how to fix the path to make it good.

Added for mga9.

stdheaders

Problem: libstdc++ changed some of its header file dependencies so that files that previously were implicitly included in older versions no longer are.

Solution: Patch the program to add the missing #include <foo> line. gcc will often give you a hint in the build log ("did you forget to '#include <foo>'?") as to the correct header file.

Added for mga9.

stdinclude

Problem: libstdc++ changed some of its header file dependencies so that files that previously were implicitly included in older versions no longer are.

Solution: Patch the program to add the missing #include <foo> line. The two most common in this round are #include <algorithm> and #include <stdint>.

More info: https://gcc.gnu.org/gcc-14/porting_to.html

Added for mga10.

toomanyargs

Problem: A function is being called that takes more arguments than are being given.

Solution: If the function does not have a prototype, gcc >= 15 assumes it takes 0 arguments, whereas previous versions did not check the number of arguments in this case. If lacking a prototype is the problem and there is no function prototype, add one in an appropriate .h file. If compiling a library, make sure that a new prototype doesn't affect backwards compatibility with older applications using the library. If it's not possible to add a prototype, you can add the -std=gnu17 compiler option (e.g. by appending to CFLAGS before the build step) to revert to the old behaviour (but don't do this to fix a library because it means that all applications using the library will also need to add the flag). If there is a prototype but it does not match the number of arguments passed in, then it is a compatibility break, likely with some dependent library, and the application will need to be patched to use the correct arguments.

Added for mga10.

unpackagedfile

Problem: The spec file is missing an entry in the %files section for a file that has been installed during the build.

Solution: This is probably due to a newer version of the application installing a new file. If so, add the new file to the %files section. If the file is not desired, then prevent it from being installed in the first place by changing the configure options, patching the makefile, or explicitly removing the file (with rm) at the end of the %install section.

Added for mga6.

wmvnconfig

Problem: The Java program using Maven has a problem with its configuration, which cannot be loaded by xmvn.

Solution: TBD

Added for mga9.