set MinGW LIBS in configure.ac, not in Makefile.am

[starius]

Fix libuv.pc on MinGW.

Previous version generates libuv.pc with LIBS = "-lpthread" instead of "-lpthread -lws2_32 -lpsapi -liphlpapi -lshell32 -luserenv" on MinGW.

Previous version generates the following Makefile.am:

am__append_4 = -lws2_32 -lpsapi -liphlpapi -lshell32 -luserenv
...
LIBS = -lpthread  $(am__append_4)

and the following configure.ac:

AS_IF([test "x$PKG_CONFIG" != "x"], [
    AC_CONFIG_FILES([libuv.pc])
])
AC_CONFIG_FILES([Makefile])

Therefore, Makefile is generated after libuv.pc. Variables from Makefile don't affect config.status and libuv.pc.

Tony Theodore proposed to set LIBS in configure.ac instead of Makefile.am and created this patch.

See also mxe/mxe#1291

[saghul]

What is the rationale behind this? I can compile libuv on MinGW just fine.

[bnoordhuis]

I think the idea is to get the list of libraries into the Libs: field in libuv.pc.in.

@starius Is this patch intended for linking against the static library? I would expect the shared library to pull in the requisite dependencies automatically.

[starius]

@saghul, this patch is needed to fix Libs in libuv.pc, as @bnoordhuis said.
@bnoordhuis, the patch is not needed on shared targets.

[saghul]

Verified the change: https://www.dropbox.com/s/mvk86birei1okjc/Screenshot%202016-04-25%2018.06.29.png?dl=0

LGTM

Now, should we apply the same principle to other platforms too?

PS: @starius I just reread my first message, sorry about that, I sound like an asshole there :-S

[starius]

Now, should we apply the same principle to other platforms too?

I have not found other platform specific additions to LIBS:

$ git grep -w LIBS
configure.ac:    LIBS="$LIBS -lws2_32 -lpsapi -liphlpapi -lshell32 -luserenv"
libuv.pc.in:Libs: -L${libdir} -luv @LIBS@

[saghul]

Landed in 9386f2c, thanks!

[TimothyGu]

Actually technically, the static-only libraries should be specified in Libs.private line of the pkg-config file, which is used only when static linking is used.

(Edit) There are no real technical negative repercussions for explicitly linking the libraries for shared usage, but when one inspect the final linked binary with tools like objdump -x the noisy libraries will show up, so it's usually considered good practice to put them in .private.

[starius]

@TimothyGu, I created new issue for that #895