[Rpm-maint] [rpm-software-management/rpm] Build fails silently when gawk is missing (Issue #2926)
**Describe the bug** The original autotools build relied on AC_PROG_AWK to choose the best awk available (gawk/mawk/nawk/awk), and I imagine it would fail if there weren't any. However, the new CMake build [expects gawk specifically](https://github.com/rpm-software-management/rpm/blob/master/lib/CMakeLists.txt), and it produces a broken build if it doesn't exist. The only clue is a warning emitted during the build (among a bunch of other normal compiler warnings and output): `lib/gentagtbl.sh: line 74: gawk: command not found` **To Reproduce** Steps to reproduce the behavior: 1. OS provides awk, but not gawk. 2. Trigger a build. 3. Try running `rpmbuild -ba …` for a valid test file. It'll fail with a bunch of errors like this: `error: (unknown) field must be present in package: (main package)` **Expected behavior** Ideally the build would fallback to awk if gawk is unavailable. At a minimum, the build should fail instead of producing a broken executable. **Environment** - OS / Distribution: MacOS 13 (Ventura) - Version rpm-4.19.1.1 **Additional context** This is loosely a follow-up to #2807 since it was noticed when testing the MacOS build more thoroughly. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2926 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM 4.19.1.1 bugfix update (PR #2888)
I confirmed that this still builds on macOS, using [these commands](https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1877296382)–the only difference being that I added `readline` to `PKG_CONFIG_PATH` like this: `PKG_CONFIG_PATH=/usr/local/opt/libarchive/lib/pkgconfig:/usr/local/opt/readline/lib/pkgconfig` So this looks great to me -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2888#issuecomment-1927664713 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.19 unbuildable on macOS due to Linux-specific extensions (Issue #2807)
Bingo! It works now: ``` mkdir _build cd _build PKG_CONFIG_PATH=/usr/local/opt/libarchive/lib/pkgconfig cmake -DENABLE_NLS=ON -DENABLE_PLUGINS=OFF -DWITH_AUDIT=OFF -DWITH_INTERNAL_OPENPGP=ON -DWITH_OPENSSL=ON -DWITH_SELINUX=OFF -DENABLE_TESTSUITE=OFF -DWITH_ACL=OFF -DWITH_CAP=OFF .. # … # [100%] Built target _rpm ./tools/rpm --version # RPM version 4.19.90 ``` Those cmake options are basically just the args listed in Homebrew's [rpm.rb](https://github.com/Homebrew/homebrew-core/blob/master/Formula/r/rpm.rb), plus `-DWITH_ACL=OFF -DWITH_CAP=OFF` since I'm guessing macOS doesn't support those features, and they were disabled by default in previous versions. So I believe that PR solves this issue completely. Happy new year! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1877296382 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.20 unbuildable on macOS due to Linux-specific extensions (Issue #2807)
```
[ 1%] Building C object misc/CMakeFiles/libmisc.dir/fts.c.o
In file included from misc/fts.c:76:
misc/system.h:87:11: fatal error: 'libintl.h' file not found
```
Added to misc/CMakeLists.txt:
`target_include_directories(libmisc PRIVATE ${Intl_INCLUDE_DIRS})`
```
[ 2%] Building C object
rpmio/rpmpgp_legacy/CMakeFiles/rpmpgp_legacy.dir/rpmpgp_internal.c.o
In file included from rpmio/rpmpgp_legacy/rpmpgp_internal.c:6:
misc/system.h:87:11: fatal error: 'libintl.h' file not found
```
Added to rpmio/rpmpgp_legacy/CMakeLists.txt:
`target_include_directories(rpmpgp_legacy PRIVATE ${Intl_INCLUDE_DIRS})`
```
[ 88%] Building C object python/CMakeFiles/_rpm.dir/rpmmodule.c.o
In file included from python/rpmmodule.c:26:
In file included from python/spec-py.h:4:
In file included from include/rpm/rpmbuild.h:9:
include/rpm/rpmcli.h:10:10: fatal error: 'popt.h' file not found
```
Added to python/CMakeLists.txt:
`target_include_directories(_rpm PRIVATE ${POPT_INCLUDE_DIRS})`
And then everything worked.
I think that last one got hidden when we tried globally including
Intl_INCLUDE_DIRS, just because it's `/usr/local/include` which includes a copy
of popt.h too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1864630360
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.20 unbuildable on macOS due to Linux-specific extensions (Issue #2807)
Close!
I didn't realize that cmake was supposed to handle this automatically, and
until now I'd been setting `CFLAGS=-I/usr/local/include` (basically hoping that
homebrew did something similar). The
`include_directories(${Intl_INCLUDE_DIRS})` makes that unnecessary because
`Intl_INCLUDE_DIRS` is `/usr/local/include`, but that also makes my local rpm
headers [fight with the headers in the
build](https://gitlab.kitware.com/cmake/cmake/-/issues/19120). So I tried
taking this advice and rearranging things:
> We don't model any ordering dependencies among include directories so you may
> need to order your `[target_]include_directories` calls accordingly.
So if I move `include_directories(${Intl_INCLUDE_DIRS})` down below
`include_directories(${CMAKE_SOURCE_DIR}/include)`, it all works.
Also the `link_directories` [isn't
needed](https://cmake.org/cmake/help/latest/command/link_directories.html),
since `Intl_LIBRARIES` is an absolute path.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1863153039
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.20 unbuildable on macOS due to Linux-specific extensions (Issue #2807)
That's great news, thanks! I've never actually tried building this myself, but I gave it a whirl on that branch. Here's some more adjustments that I had to make: * Added `PRIVATE intl` to `target_link_libraries` for librpm, librpmbuild, librpmio, librpmsign, and a bunch of executables (rpm, rpm2archive, rpmbuild, rpmdb, rpmgraph, rpmkeys, rpmsign, and rpmspec). - I don't really understand the difference between PRIVATE and PUBLIC. Maybe putting it somewhere as PUBLIC would've worked better, without having to add it to each thing individually? - Setting `ENABLE_NLS=OFF` makes this unnecessary. But when it's on, I'd think it should link against the necessary libraries automatically. * Added `PRIVATE iconv` to `target_link_libraries` for librpmbuild. * Added `PRIVATE popt` to `target_link_libraries` for librpmsign. * Added `#include ` to `rpm2archive.c`, which seems to be needed for POSIX compatibility. Otherwise it was complaining about the basename call added in #2758. * Removed `PkgConfig::LIBDW` and `PkgConfig::LIBELF` from `target_link_libraries` for librpmbuild. Obviously not recommending all of these changes literally–this was just the easiest way for me to map out all of the potential issues remaining. I tried deciphering #2238 to see which of these might've been lost in the CMake transition, but I figure y'all would be better at figuring that out. I'm also not 100% sure that I'm running cmake exactly as Homebrew would. So if any of this was supposed to work already, then I might've just been doing something strange. Just wanted to throw this up there in case it's helpful. Thanks again! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1861352659 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] 4.20 unbuildable on macOS due to Linux-specific extensions (Issue #2807)
This is similar to #, but I read the conclusion there as "the RPM team won't bend over backwards to support an OS that isn't POSIX complaint," which makes perfect sense to me. Now, macOS has added the missing POSIX function described in that issue, but 4.20 won't build for different reasons: * #2046 now requires a GNU extension `GLOB_ONLYDIR` * #2249 now requires a GNU extension `strchrnul` * [elfdeps target links against libelf from elfutils](https://github.com/rpm-software-management/rpm/blob/rpm-4.19.0-release/CMakeLists.txt#L416), but elfutils is Linux-only. I can't quite follow exactly how this was introduced, maybe #2302 * And possibly a few others. (I'm getting this list of examples from [here](https://github.com/orgs/Homebrew/discussions/4826#discussioncomment-7779025).) The discussion for #2046 even acknowledges that it'll break POSIX compatibility: > Portability sucks, for the developers. If this becomes an actual issue, we'll > look into integrating gnulib rather than maintaining our own copy. It sounds like the Homebrew team has basically given up on trying to build rpm for macOS, so I wanted to open this issue to clarify if that's warranted or not. If we should expect every new version to break POSIX compatibility, then I'd agree that probably makes sense. But I'm not sure if that's the actual intent? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2807 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
