search

pfalcon / berkeley-db-1.xx

Berkeley DB 1.85 with patches and fixes applied
24 stars 18 forks source link

sys/cdefs.h is an internal glibc header and should not be used #2

Open alex-v77 opened 6 years ago

alex-v77 commented 6 years ago

The include/db.h file includes sys/cdefs.h which is an internal glibc header that may not exist in other libc implementations and thus should not be used.

Compilation with musl libc fails:

In file included from ../../lib/berkeley-db-1.xx/btree/bt_seq.c:48:0: ../../lib/berkeley-db-1.xx/PORT/include/db.h:40:23: fatal error: sys/cdefs.h: No such file or directory compilation terminated. In file included from ../../lib/berkeley-db-1.xx/btree/bt_split.c:48:0: ../../lib/berkeley-db-1.xx/PORT/include/db.h:40:23: fatal error: sys/cdefs.h: No such file or directory compilation terminated. In file included from ../../lib/berkeley-db-1.xx/btree/bt_utils.c:47:0: ../../lib/berkeley-db-1.xx/PORT/include/db.h:40:23: fatal error: sys/cdefs.h: No such file or directory compilation terminated. In file included from ../../lib/berkeley-db-1.xx/mpool/mpool.c:46:0: ../../lib/berkeley-db-1.xx/PORT/include/db.h:40:23: fatal error: sys/cdefs.h: No such file or directory compilation terminated. [...other files of berkeley-db include db.h too...]

pfalcon commented 6 years ago

Did you try to report this to musl, that they aren't compatible with well-known software like BerkeleyDB?

I hope to get to building with musl eventually and see what should be done.

alex-v77 commented 6 years ago

They are aware of the issues with sys/cdefs.h.

From their FAQ:

https://wiki.musl-libc.org/faq.html#Q:-When-compiling-something-against-musl,-I-get-error-messages-about-%3Ccode%3Esys/cdefs.h%3C/code%3E

"Q: When compiling something against musl, I get error messages about sys/cdefs.h" [...] "The bug is in the application that uses this internal glibc header. This header is not intended to be used by any program."

and in my opinion they're right, this header should not be used.

pfalcon commented 6 years ago

They're apparently wrong with at least one point - that it's internal glibc header, apparently it comes from BSD and/or SysV times.

Feel free to propose a patch, should be simple I guess. But please feel free to test with glibc, musl, newlib, uclibc, bionic. (Or somebody else might need to test.)