#67883 closed defect (fixed)
rpki-client @8.5: error: implicit declaration of function 'mkostemp' is invalid in C99
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | artkiver (グレェ) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.8.1 |
| Keywords: | Cc: | ||
| Port: | rpki-client |
Description
CC rpki_client-output.o
CC rpki_client-parser.o
CC rpki_client-print.o
CC rpki_client-repo.o
output.c:137:7: error: implicit declaration of function 'mkostemp' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
fd = mkostemp(output_tmpname, O_CLOEXEC);
^
output.c:137:7: note: did you mean 'mkstemp'?
/usr/include/stdlib.h:201:6: note: 'mkstemp' declared here
int mkstemp(char *);
^
1 error generated.
make[1]: *** [rpki_client-output.o] Error 1
make[1]: *** Waiting for unfinished jobs....
And please disable silent rules.
Change History (4)
comment:1 Changed 3 years ago by artkiver (グレェ)
comment:2 Changed 3 years ago by artkiver (グレェ)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:3 Changed 3 years ago by artkiver (グレェ)
After sleeping on this I realized I may have prematurely closed this because I didn't test on El Capitan, so not seeing the same build error locally wasn't a reflection of that version of OS X. I'll check into it later, but if this is flagged again in the build bots, my apologies! I will re-open it if necessary.
comment:4 Changed 9 months ago by barracuda156
This is broken again:
mv -f .deps/rpki_client-output-json.Tpo .deps/rpki_client-output-json.Po /usr/bin/gcc-4.2 -std=gnu99 -std=gnu99 -DPACKAGE_NAME=\"rpki-client\" -DPACKAGE_TARNAME=\"rpki-client\" -DPACKAGE_VERSION=\"9.7\" -DPACKAGE_STRING=\"rpki-client\ 9.7\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"rpki-client\" -DVERSION=\"9.7\" -DSPT_TYPE=SPT_REUSEARGV -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DSIZEOF_TIME_T=4 -DHAVE_SETGROUPS=1 -DHAVE_SETREGID=1 -DHAVE_SETREUID=1 -DHAVE_STRLCAT=1 -DHAVE_STRLCPY=1 -DHAVE_ARC4RANDOM_UNIFORM=1 -DHAVE_INET_NET_PTON=1 -DHAVE_FTS_H=1 -DHAVE_FTS_OPEN=1 -DHAVE_ERR_H=1 -DHAVE_OPENSSL_CMS_H=1 -DHAVE_OPENSSL_ERR_H=1 -DHAVE_OPENSSL_EVP_H=1 -DHAVE_OPENSSL_SSL_H=1 -DHAVE_OPENSSL_X509_H=1 -DHAVE_OPENSSL_X509V3_H=1 -DHAVE_LIBCRYPTO=1 -DHAVE_X509_UP_REF=1 -DHAVE_ASIDENTIFIERS_FREE=1 -DHAVE_IPADDRESSRANGE_FREE=1 -DHAVE_X509V3_ADDR_IS_CANONICAL=1 -DHAVE_X509V3_ASID_IS_CANONICAL=1 -DHAVE_TLS_H=1 -DHAVE_TLS_DEFAULT_CA_CERT_FILE=1 -DHAVE_TLS_CONFIG_SET_CA_MEM=1 -DHAVE_X509_GET0_UIDS=1 -DHAVE_X509_CRL_GET0_TBS_SIGALG=1 -DHAVE_EXPAT_H=1 -DHAVE_LIBEXPAT=1 -DHAVE_XML_PARSE=1 -DHAVE_XML_SETUSERDATA=1 -DHAVE_ZLIB_H=1 -DHAVE_LIBZ=1 -DHAVE_INFLATE=1 -DHAVE_INFLATEEND=1 -DHAVE_INFLATERESET=1 -DRPKI_CLIENT_USER=\"_rpki-client\" -DRPKI_RSYNC_CMD=\"rsync\" -I. -I../include -I../src -I/opt/local/include -I/opt/local/include/LegacySupport -DOPENSSL_SUPPRESS_DEPRECATED -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wsign-compare -Werror-implicit-function-declaration -Wno-pointer-sign -DRPKI_PATH_TAL_DIR=\"/opt/local/etc/rpki\" -DRPKI_PATH_BASE_DIR=\"/opt/local/var/cache/rpki-client\" -DRPKI_PATH_OUT_DIR=\"/opt/local/var/db/rpki-client\" -pipe -Os -I/opt/local/include/LegacySupport -arch ppc -MT rpki_client-output.o -MD -MP -MF .deps/rpki_client-output.Tpo -c -o rpki_client-output.o `test -f 'output.c' || echo './'`output.c output.c: In function ‘output_createtmp’: output.c:179: error: implicit declaration of function ‘mkostemp’ make[1]: *** [rpki_client-output.o] Error 1 make[1]: *** Waiting for unfinished jobs....
Note: See
TracTickets for help on using
tickets.

Thanks for that! I brought this to the attention of one of the rpki-client developers, Job Snijders who in turn seemed to think it looked like this issue:
https://github.com/att/ast/issues/976
Given the apparent fix there (e.g. https://github.com/att/ast/commit/f85990193bfc14bb88924511ec2d93ad78d536c3 ) I am wondering if a similar approach might be worthwhile, perhaps using legacy-support or legacy-support-devel?