[poppler] poppler ported to Mingw+MSys

Albert Astals Cid aacid at kde.org
Thu Sep 25 13:56:48 PDT 2008


A Dijous 25 Setembre 2008, carlo.bramix va escriure:
> Hello,
>
> > > I tried to compile poppler under mingw+msys.
> > > With some fixes I was able to compile it successfully.
> > > I did my changes on the latest git checkout.
> > > Description of changes into attached patch:
> > >
> > > glib/Makefile.am
> > > added support for shared library generation to libpoppler-glib.
> >
> > libpoppler-glib is created as a shared library on linux is that
> > @create_shared_lib@ needed for windows?
>
> Yes, @create_shared_lib@ is required for windows (and perhaps on other
> platforms too) because libtool cannot create shared libraries if
> "-no-undefined" is not specified. BTW, after your email I gave a look into
> configure.ac and I found this text where @create_shared_lib@ is defined:
>
> mingw|mingw32)
>
> Perhaps it would be better to modify that line into:
>
> mingw*)

So you mean that with that change, the @create_shared_lib@ is not needed?

>
> so it will be able to work even with mingw64 (for 64 bit editions) and
> mingwce (for Windows Mobile).
>
> > > test/Makefile.am
> > > The linking of pdf_inspector generated thousand of unresolved
> > > externals; I had to link with $(top_builddir)/glib/libpoppler-glib.la
> > > instead of $(top_builddir)/poppler/libpoppler-cairo.la for solving the
> > > trouble.
> >
> > pdf_inspector does not seem to use libpopplerglib at all, so the problem
> > is probably a different one, can you post a list of the unresolved
> > symbols?
>
> I moved that list in the bottom of this message just to make this email
> more readable.

All that missing symbols should already be in libpoppler that is being linked 
in, so the problem is some other. As a temporary solution you can link 
against libpopplerglib but i won't upload that to the repository 
because "it's the wrong thing" (TM)

>
> > > At the end everything seemed solved unless a little detail...
> > > At the beginning libjpeg was not found at configure time; infact this
> > > happens because of this line into libjpeg.m4:
> > >
> > > jpeg_incdirs="`eval echo $includedir` /usr/include /usr/local/include "
> > >
> > > Since under mingw the include files are normally under /mingw/include
> > > and not under /usr/include or /usr/local/include, I had to add
> > > "--includedir=/mingw/include". In that manner, it was able to find my
> > > libraries correctly but when I launch "make install" the include files
> > > of poppler are installed under /mingw/include instead of the location
> > > specified with "--prefix". So, I'm wondering if it's possible to add an
> > > option to configure script like "--with-jpeg-include=<path>" so that an
> > > user could specify a libjpeg path without loosing the installation
> > > path.
> >
> > Or we could add /mingw/include to the libjpeg.m4 if that is the typical
> > location of the mingw includes.
>
> Yes, I think it's safe to assume those include files are always under
> /mingw/include. Anyways, if I can give my suggestion, it won't be a bad
> idea to add an option like the one I suggested, because if a day will come
> a new XYZ system with include files into another different location, you
> must add them manually again and rebuild the configure script with
> autoconf.

Yeah right, but i have very very few interest in doing it the right way, 
autofoo is not my friend either.

Albert

>
> Sincerely,
>
> Carlo Bramini.
>
>
>
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler




More information about the poppler mailing list