MinGW and "warning: implicit declaration of function _spawnv"

[Jeffrey Walton]

I'm testing on MinGW (). I'm surprised how easily the library built
for MinGW under Autotools. Hat's off for the good job.

I'm down to one error from what appears to be an Automake source file
(see below). I'm not a MinGW expert and searching is not returning
useful results. I test the platform to get in front of problems users
may experience.

I'm not sure how to workaround the issue. Do I add a uniform name
target for lt-cryptest.c and give it special flags? Maybe something
like:

ltcryptest_CXXFLAGS = $(AM_CXXFLAGS) <some other flag>

Or maybe something else?

Thanks in advance.

Jeff

******************************

$ make
make all-am
make[1]: Entering directory '/home/Jeff/cryptopp'
/bin/sh ./libtool --tag=CXX --mode=link g++ -pthread
-fdata-sections -ffunction-sections -pipe
-DCRYPTOPP_DATA_DIR='"@pkgdatadir@/cryptopp/"' -g -O2 -pthread
-Wl,--gc-sections -o cryptest.exe cryptest-test.o cryptest-bench1.o
cryptest-bench2.o cryptest-validat0.o cryptest-validat1.o
cryptest-validat2.o cryptest-validat3.o cryptest-datatest.o
cryptest-regtest1.o cryptest-regtest2.o cryptest-regtest3.o
cryptest-dlltest.o cryptest-fipsalgt.o cryptest-adhoc.o libcryptopp.la
libtool: link: g++ -pthread -fdata-sections -ffunction-sections -pipe
-DCRYPTOPP_DATA_DIR=\"@pkgdatadir@/cryptopp/\" -g -O2 -pthread
-Wl,--gc-sections -o .libs/cryptest.exe cryptest-test.o
cryptest-bench1.o cryptest-bench2.o cryptest-validat0.o
cryptest-validat1.o cryptest-validat2.o cryptest-validat3.o
cryptest-datatest.o cryptest-regtest1.o cryptest-regtest2.o
cryptest-regtest3.o cryptest-dlltest.o cryptest-fipsalgt.o
cryptest-adhoc.o ./.libs/libcryptopp.a -pthread
./.libs/lt-cryptest.c: In function 'main':
./.libs/lt-cryptest.c:319:16: warning: implicit declaration of
function '_spawn ' [-Wimplicit-function-declaration]
rval = (int) _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz);
^~~~~~~
/tmp/ccuZVZU6.o: In function `main':
/home/Jeff/cryptopp/./.libs/lt-cryptest.c:319: undefined reference to `_spawnv'
/home/Jeff/cryptopp/./.libs/lt-cryptest.c:319:(.text.startup+0x4b4):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_spawnv'
collect2: error: ld returned 1 exit status
strip: './cryptest.exe': No such file
./libtool: line 11083: ./cryptest.exe: No such file or directory
/bin/sh ./libtool --tag=CXX --mode=link g++ -pthread
-fdata-sections -ffunction-sections -pipe -g -O2 -pthread
-Wl,--gc-sections -o cryptestcwd.exe cryptestcwd-test.o
cryptestcwd-bench1.o cryptestcwd-bench2.o cryptestcwd-validat0.o
cryptestcwd-validat1.o cryptestcwd-validat2.o cryptestcwd-validat3.o
cryptestcwd-datatest.o cryptestcwd-regtest1.o cryptestcwd-regtest2.o
cryptestcwd-regtest3.o cryptestcwd-dlltest.o cryptestcwd-fipsalgt.o
cryptestcwd-adhoc.o libcryptopp.la
libtool: link: g++ -pthread -fdata-sections -ffunction-sections -pipe
-g -O2 -pthread -Wl,--gc-sections -o .libs/cryptestcwd.exe
cryptestcwd-test.o cryptestcwd-bench1.o cryptestcwd-bench2.o
cryptestcwd-validat0.o cryptestcwd-validat1.o cryptestcwd-validat2.o
cryptestcwd-validat3.o cryptestcwd-datatest.o cryptestcwd-regtest1.o
cryptestcwd-regtest2.o cryptestcwd-regtest3.o cryptestcwd-dlltest.o
cryptestcwd-fipsalgt.o cryptestcwd-adhoc.o ./.libs/libcryptopp.a
-pthread
./.libs/lt-cryptestcwd.c: In function 'main':
./.libs/lt-cryptestcwd.c:319:16: warning: implicit declaration of
function '_spawnv' [-Wimplicit-function-declaration]
rval = (int) _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz);
^~~~~~~
/tmp/ccENXptt.o: In function `main':
/home/Jeff/cryptopp/./.libs/lt-cryptestcwd.c:319: undefined reference
to `_spawnv'
/home/Jeff/cryptopp/./.libs/lt-cryptestcwd.c:319:(.text.startup+0x4b4):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_spawnv'
collect2: error: ld returned 1 exit status
strip: './cryptestcwd.exe': No such file
./libtool: line 11083: ./cryptestcwd.exe: No such file or directory
make[1]: Leaving directory '/home/Jeff/cryptopp'

[Jeffrey Walton]

Post by Jeffrey Walton
I'm testing on MinGW (). I'm surprised how easily the library built
for MinGW under Autotools. Hat's off for the good job.
I'm down to one error from what appears to be an Automake source file
(see below). I'm not a MinGW expert and searching is not returning
useful results. I test the platform to get in front of problems users
may experience.
I'm not sure how to workaround the issue. Do I add a uniform name
target for lt-cryptest.c and give it special flags? Maybe something
ltcryptest_CXXFLAGS = $(AM_CXXFLAGS) <some other flag>
Or maybe something else?

It looks like the extra files provided by libtool are the problem. It
looks like the libtool folks need to add _XOPEN_SOURCE=600 to their
preprocessor definitions. I'm guessing they only test with a C
compiler, and not a C++ compiler and Newlib combination.

Let me move this to a libtool mailing list.

Jeff

...
./.libs/lt-cryptestcwd.c: In function 'main':
./.libs/lt-cryptest.c: In function 'main':
./.libs/lt-cryptestcwd.c:319:16: warning: implicit declaration of
function '_spawnv' [-Wimplicit-function-declaration]
rval = (int) _spawnv (_P_WAIT, lt_argv_zero, (const char * const *) newargz);
^~~~~~~
...

[Bob Friesenhahn]

Post by Jeffrey Walton

Post by Jeffrey Walton
Or maybe something else?

It looks like the extra files provided by libtool are the problem. It
looks like the libtool folks need to add _XOPEN_SOURCE=600 to their
preprocessor definitions. I'm guessing they only test with a C
compiler, and not a C++ compiler and Newlib combination.

What does spawnv have to do with _XOPEN_SOURCE? Isn't spawnv a
Microsoft Windows-specific function and _XOPEN_SOURCE is a Unix thing?

You are on the right track that CFLAGS options or additional
pre-processor definitions are likely needed.

It is my understanding that the MinGW headers and library may support
multiple CRT versions but the default is the CRT version assured to
come with any Windows system, which leaves many functions out.

Bob

[Jeffrey Walton]

On Tue, Nov 14, 2017 at 4:00 PM, Bob Friesenhahn

Post by Jeffrey Walton

Post by Jeffrey Walton
Or maybe something else?

It looks like the extra files provided by libtool are the problem. It
looks like the libtool folks need to add _XOPEN_SOURCE=600 to their
preprocessor definitions. I'm guessing they only test with a C
compiler, and not a C++ compiler and Newlib combination.

What does spawnv have to do with _XOPEN_SOURCE? Isn't spawnv a Microsoft
Windows-specific function and _XOPEN_SOURCE is a Unix thing?

I think spawn is Posix, and its for systems that don't have fork.
posix_spawn and _spawn are deprecated on MS platforms. They use an ISO
C++ version called spawnl. Also see
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnl-wspawnl.

Its been my experience that when something Posix goes missing when
using Newlib the first thing to try is _XOPEN_SOURCE=500 or
_XOPEN_SOURCE=600. _XOPEN_SOURCE sets _POSIX_SOURCE and a couple of
others, like some X11 defines.

Adding _XOPEN_SOURCE=600 to flags clears the issue for me, but I
prefer not to use it. The flags are supposed to be consistent among
libraries and programs, so I have to tell users to add it too. RTFM
has not really worked in the last 50 years or so, and most people will
naturally omit it, so I would like to drop the additional requirement.

Jeff

[Bob Friesenhahn]

Post by Jeffrey Walton

What does spawnv have to do with _XOPEN_SOURCE? Isn't spawnv a Microsoft
Windows-specific function and _XOPEN_SOURCE is a Unix thing?

I think spawn is Posix, and its for systems that don't have fork.
posix_spawn and _spawn are deprecated on MS platforms. They use an ISO
C++ version called spawnl. Also see
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnl-wspawnl.

I was not aware of that.

Post by Jeffrey Walton
Its been my experience that when something Posix goes missing when
using Newlib the first thing to try is _XOPEN_SOURCE=500 or
_XOPEN_SOURCE=600. _XOPEN_SOURCE sets _POSIX_SOURCE and a couple of
others, like some X11 defines.

The problem with _XOPEN_SOURCE and _POSIX_SOURCE is that in addition
to enabling features, they also disable all the features which are not
defined by that standard. If the OS does not support the requested
version, then none of the expected features are available. Usually
there is a better way.

Regardless, Windows only conformed to the 1989 version of POSIX so
that they could say that Windows NT was compliant with the
specification so that they could sell it into goverment contracts.

Bob