On 10/12/2011 2:35 PM, Erwin Waterlander wrote:
> My application (wcd) needs libunistring
> (http://www.gnu.org/s/libunistring/) for Unicode normalisation. I'm
> willing to package and maintain libunistring for Mingw. I already do
> this for Cygwin.
MinGW, at present, doesn't intend to be a repository of all possible
packages ported to win32. Right now, the only packages we provide, in
the -mingw32- subsystem, fall into two categories, with a few historical
1) development tools like auto* (and gcc itself, with its
supporting libraries, of course). This includes the
libiconv and libintl libraries, because they are needed, in
mingw form, in order for the gettextize tool (&friends) to
2) a few compression libraries (zlib, bzip, xz, libarchive)
which are needed to support mingw-get.exe development.
Stuff like PDCurses falls under the "historical exception" because long
ago, there used to be a PDCurses mingwPORT "contrib" item, and somebody
offered to update it to make it "mingw-get" compatible.
We haven't really had the discussion about handling additional packages.
I think that deserves its own thread, to consider the issues: What do
we do about "contributed" mingw32 libraries and exes? Should they even
be considered for acceptance as part of the mingw.org packageset? Should
that be a separate project (with its own mingw-get-compatible
repository?) OR, should it be managed as an intrinsic part of the
"core" offerings here @ mingw.org? Policies & procedures?
> I used portmaker to create the mingwPORT scripts. Libunistring compiles
> without problems, out-of-the-box,
FYI, you might want to try the new 'mgwport' package -- which should
allow you to reuse (a lot of) your .cygport scripts from your cygwin
Unlike portmaker/mingwPORT, mgwport is intended for creating binary
tarballs for distribution. mingwPORT, OTOH, is meant for distributing
"recipes" that end users can use to build the binaries themselves, and
requires some hacking to make it work for the bindist purpose.
> but at the very end the linking step
> ends with this error:
> libtool: link: gcc -shared .libs/libunistring.la.lnkscript
> -Lc:/msys/1.0/mingw/lib /mingw/lib/libiconv.dll.a -mms-bitfields
> -march=i686 -Wl,--export-all-symbols -Wl,--disable-auto-import -o
> .libs/libunistring-0.dll -Wl,--enable-auto-image-base -Xlinker
> --out-implib -Xlinker .libs/libunistring.dll.a
Because gcc is not invoked with -pthread (nor is -lpthread added to the
link command). Why libtool is "doing it wrong" I don't know, you'll
have to investigate. (FWIW, the use of a link script
'.libs/libunistring.la.lnkscript' looks suspicious to me)