Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libintl.h file not found #470

Open
kev009 opened this issue Mar 5, 2022 · 8 comments
Open

libintl.h file not found #470

kev009 opened this issue Mar 5, 2022 · 8 comments
Assignees
Labels
help wanted Extra attention is needed sys:*-freebsd

Comments

@kev009
Copy link

kev009 commented Mar 5, 2022

OS is FreeBSD. pgx is 0.4.0-beta-0. It seems to get pretty close to the end but then is missing a C header which would be in /usr/local.

cargo pgx init --pg13 pg_config with pg_config showing the correct INCLUDEDIR = /usr/local/include

kev-ws-aurora% cargo pgx run pg13
building extension with features ``
"cargo" "build" "--message-format=json-render-diagnostics"
   Compiling pgx-pg-sys v0.4.0-beta.0
error: failed to run custom build command for `pgx-pg-sys v0.4.0-beta.0`

Caused by:
  process didn't exit successfully: `/usr/home/kev009/pgxtest/target/debug/build/pgx-pg-sys-661c1c5f07b27fdc/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-env-changed=PGX_PG_SYS_GENERATE_BINDINGS_FOR_RELEASE
  cargo:rerun-if-changed=/home/kev009/.pgx/config.toml
  cargo:rerun-if-changed=include/pg10.h
  cargo:rerun-if-changed=include/pg11.h
  cargo:rerun-if-changed=include/pg12.h
  cargo:rerun-if-changed=include/pg13.h
  cargo:rerun-if-changed=include/pg14.h
  cargo:rerun-if-changed=cshim/pgx-cshim.c
  cargo:rerun-if-changed=cshim/Makefile

  --- stderr
  manifest_dir=/home/kev009/.cargo/registry/src/github.com-1ecc6299db9ec823/pgx-pg-sys-0.4.0-beta.0
  shim_src=/home/kev009/.cargo/registry/src/github.com-1ecc6299db9ec823/pgx-pg-sys-0.4.0-beta.0/cshim
  shim_dst=/usr/home/kev009/pgxtest/target/debug/build/pgx-pg-sys-86f7123a0f3e30bb/out/cshim
  Generating bindings for pg13
  /usr/local/include/postgresql/server/c.h:75:10: fatal error: 'libintl.h' file not found
  /usr/local/include/postgresql/server/c.h:75:10: fatal error: 'libintl.h' file not found, err: true
  thread 'main' panicked at 'Unable to generate bindings for pg13: ()', /home/kev009/.cargo/registry/src/github.com-1ecc6299db9ec823/pgx-pg-sys-0.4.0-beta.0/build.rs:512:13
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
@Hoverbear
Copy link
Contributor

Thanks for reporting this! Hmm... I don't currently have a freeBSD machine to reproduce this on.

@workingjubilee workingjubilee added sys:*-freebsd help wanted Extra attention is needed labels Aug 12, 2022
@JonyEpsilon
Copy link

JonyEpsilon commented Nov 6, 2022

This is a bit of a drive-by, as I know almost nothing about rust, cargo, or pgx! But maybe it'll be helpful anyway ...

I came across this error trying to build the databases/postgres-promscale extension on FreeBSD (https://cgit.freebsd.org/ports/tree/databases/postgresql-promscale). I've proposed a patch to "fix" it on this bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267550 . That's a patch to the promscale extension port, as it vendors in its own version of pgx. But I think the problem is a pgx problem rather than a promscale-specific problem.

My best guess is that there's an assumption baked in to the pgx-pg-sys buildgen code that 'libintl.h' will be located in /usr/include. On FreeBSD it's by default in /usr/local/include because it ships as part of a package (devel/gettext-runtime) rather than as part of the base system. The location of this local include directory is included in an environment variable set by the ports make system, CPPFLAGS (you can see the full cargo command being executed by the ports make system, for the vendored pgx in the promscale extension, in this comment https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267550#c4 ).

So, maybe it's possible that this flag isn't being read by the buildgen code, and so the include directory is not being flagged to clang? I did notice this commit 6aaad98 while poking around the source, which adds some extra clang flags on MacOS. Maybe something in a similar spirit is needed to support FreeBSD?

Anyway, I may be off-base here - so take this with a pinch of salt - but maybe something in there helps.

@workingjubilee
Copy link
Member

@JonyEpsilon That is not the right solution, and also it is not quite a PGX bug.

libintl.h is not an actual dependency of PGX at all. It is only bound against because rust-bindgen, by default, eagerly binds against transitive header dependencies, because it does not have the sense of whether a symbol actually requires a certain header in order to resolve its definition (not necessarily to compile it, which of course might require everything and then the kitchen sink). We do require postgres.h, but that includes c.h, which, if the build was instructed to ENABLE_NLS, includes libintl.h. But we don't need any of the definitions from that! PGX extensions should not need to use gettext: there are in-Rust for-Rust solutions for that facility.

I have opened #940 to attempt to resolve this by directing bindgen to omit c.h and its definitions from the bindings, as I believe this should solve the problem for all OS. But if this does not solve the problem on BSDs, you may want to instead try to explicitly add .blocklist_file("libintl.h"). Again, we do not use it and should not need it as part of the build.

@JonyEpsilon
Copy link

Ahh, interesting. Thanks for taking the time to write the explanation :-)

If I remove the additional clang_arg and try adding either .blocklist_file("libintl.h") or .blocklist_file("c.h") I find that neither of them lead to a successful build on FreeBSD. The error is as before:

/usr/local/include/postgresql/server/c.h:75:10: fatal error: 'libintl.h' file not found

(It should noted that this against the 0.7.0 release, which is what targeted by the FreeBSD port, not against HEAD.)

I would speculate that something is trying to resolve the path to the file before the blocking is happening, but at this point I'm just making stuff up, as I've no idea how bindgen works!

@sumerman
Copy link
Contributor

I'm getting this same message when trying to run cargo pgrx init against PostgreSQL 15 from brew.

@thomcc
Copy link
Contributor

thomcc commented Jul 12, 2023

You probably have to run brew info gettext (and maybe some other packages, we should document this better/find PG's docs on it -- as of pg16 you'll need brew install icu4c too...)

Also note that we don't use the PostgreSQL you install globally except for a couple commands like package/install, so having installed it via brew doesn't really exempt you from these issues.

(Also, if you don't have it set up, make sure you have XCode and the CommandLineTools package installed, and make sure you've opened XCode at least once since installing)

@samay-sharma
Copy link

samay-sharma commented Aug 1, 2023

I was running into the same issue on a Mac while trying to run cargo pgrx install --release for https://github.com/tembo-io/pgmq even though I had libint.h present.

locate libintl
/Applications/Docker.app/Contents/Resources/lib/libintl.8.dylib
/opt/homebrew/Cellar/gettext/0.21.1/include/libintl.h
/opt/homebrew/Cellar/gettext/0.21.1/lib/libintl.8.dylib
/opt/homebrew/Cellar/gettext/0.21.1/lib/libintl.a
/opt/homebrew/Cellar/gettext/0.21.1/lib/libintl.dylib
/opt/homebrew/include/libintl.h
/opt/homebrew/lib/libintl.8.dylib
/opt/homebrew/lib/libintl.a
/opt/homebrew/lib/libintl.dylib

I was able to fix it by running export BINDGEN_EXTRA_CLANG_ARGS='-I"/opt/homebrew/include"' as indicated here: https://github.com/rust-lang/rust-bindgen

@thomcc
Copy link
Contributor

thomcc commented Aug 2, 2023

It looks like this happens if you do cargo pgrx init --pgwhatever=$(which pg_config), e.g. use the system postgres. It can be fixed by handling it around

fn extra_bindgen_clang_args(pg_config: &PgConfig) -> eyre::Result<Vec<String>> {
or so, I think. It needs to be changed to look at the includes in --cppflags and such.

@thomcc thomcc self-assigned this Aug 2, 2023
eeeebbbbrrrr pushed a commit that referenced this issue Aug 10, 2023
…1247)

We should consider doing this on other targets too (I think technically
we would be fine to always do this), but I'd rather not make a big
change like that on the targets people use for production DBs, at least
not without more testing (and possibly a escape hatch to opt out).

This is for #470 and fixes it on macOS, but since the bug was reported
on FreeBSD too, I'm not sure we should close it until it's done more
broadly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed sys:*-freebsd
Projects
None yet
Development

No branches or pull requests

7 participants