Re: libsoup on MS Windows problems

[Tor Lillqvist <tml iki fi>]

> I find it a little strange, as I would expect that a series of default
> installations of packages that depends on each other would be working
> without having to add any options or environment variables to the configure
> script.

What packages, downloaded from where, are you talking about specifically?

> And traditionally the configure script by default uses /usr/local as prefix
> for installation.

Quite irrelevant for pkg-config (or any other software) built for
*Windows*. There is no "/usr/local" on Windows. A Unix emulation like
MSYS (in which term I do *not* include MinGW) might have a such
directory, but even then, users intent on using /usr/local the same
way as traditionally on Unix are sometimes not really understanding
what it means to build software for "native" Windows, even if the
*build* environment happens to look a bit like Unix..

> So my expectation has nothing to do with pkg-config as such, eventhough
> pkg-config is used under the hood.

OK. So your wish would be that the PKG_* stuff in a configure.ac (or
configure.in) file would automatically cause $prefix/lib/pkgonfig and
$prefix/share/pkgconfig to be added to PKG_CONFIG_PATH when running
pkg-config? Yeah, I guess that could indeed be a good idea. It might
in some cases cause regressions, though, especially if said
directories were added in front of the PKG_CONFIG_PATH environment
variable. Placing them at the end is probably better. Please file a
bug against pkg-config.

> CCLD   libsoup-2.4.la
> Opretter biblioteksfil: .libs/libsoup-2.4.dll.a

So now it does create a DLL and an import library for it. Please
verify with pexports that the DLL indeed exports the expected soup_*
functions, and with nm that they indeed are present in the import
library. If not, run make V=1 to see more verbose output.

> CCLD   chunk-test.exe
> chunk-test.o:chunk-test.c:(.text+0x95): undefined reference to
> `soup_message_body_append_buffer'

Does this link against the libsoup (import) library as it should? If
yes, then it seems that either the DLL does not export the functions
it should, or the import library does not contain the symbols ("import
stubs") for the exported functions.

--tml