Bug 9139 - Fixed for the build to work in native MSYS environment
Summary: Fixed for the build to work in native MSYS environment
Status: RESOLVED WONTFIX
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
: 9137 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-11-23 00:54 UTC by Alexis Wilke
Modified: 2011-06-19 16:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch to compile under MSYS (3.56 KB, patch)
2006-11-23 00:55 UTC, Alexis Wilke
Details | Splinter Review

Description Alexis Wilke 2006-11-23 00:54:15 UTC
Just trying to keep you busy. I will post a patch with this entry.

I made a few changes to get everything to compile under MSYS/MinGW with
glib-2.0, libjpeg, libz.

I can create a .DLL with one run. I turn off the utils to avoid problems with
different elements missing for them. I do not need them at this time.

Everything compiles & installs like a charm with these changes. I would
appreciate the changes to the configure.ac and Makefile.am to get the DLLs to
work as is in future versions.

The change in the m4/libjpeg.m4 file would be nice since it is really a bug.

The change to poppler/CairoFontEngine.cc may look strange, but under MinGW the
unlink() command is defined in the io.h header file which is included from the
unistd.h header...

The configure.ac fix includes the move of the poppler/poppler-config.h file from
the AM_CONFIG_HEADER() to the AC_OUTPUT().

Hope this helps some other people too.

Thank you for taking the time to apply these changes.

Alexis W.
Comment 1 Alexis Wilke 2006-11-23 00:55:36 UTC
Created attachment 7882 [details] [review]
Patch to compile under MSYS

See previous comment for info about this patch (bug 9139)
Comment 2 Alexis Wilke 2006-11-23 11:58:12 UTC
*** Bug 9137 has been marked as a duplicate of this bug. ***
Comment 3 Albert Astals Cid 2006-11-23 13:12:13 UTC
I don't like much removing the AM_CONFIG_HEADER, does this work for you?

-AM_CONFIG_HEADER(config.h)
-AM_CONFIG_HEADER(poppler/poppler-config.h)
+AC_CONFIG_HEADERS([config.h:config.h.in])
+AC_CONFIG_HEADERS([poppler/poppler-config.h:poppler/poppler-config.h.in])
Comment 4 Alexis Wilke 2006-11-23 18:36:35 UTC
Okay, I have to say that there is currently a problem with the config.h file.

You define the file named poppler-config.h.in in the poppler directory. That
file has different configuration information that you say come from the
$(topdir)/config.h file. This is not correct. What you need to do is include the
config.h file. If you need to install it (which is a problem I ran into!) then
you need to use the AC_CONFIG_HEADERS () and rename (and possibly move!) that
header file.

The poppler-config.h.in, as it stands, is NOT an AC_CONFIG_HEADERS(). Actually,
at some point, I deleted it thinking that it was. It is not since it has
additional information that the autoreconf tool suite cannot regenerate. So it
is a header you created. Clearly!

What I'd suggest is something like that:

poppler/poppler-config.h
+#include <config.h>
-<all these #ifndef <blah> which are in config.h>

configure.ac
-AC_CONFIG_HEADERS([config.h:config.h.in])
+AC_CONFIG_HEADERS([poppler/config.h:poppler/config.h.in])
-AC_CONFIG_HEADERS([poppler/poppler-config.h:poppler/poppler-config.h.in])

You may want to talk about this to other autoconf savvy people...

If you need to install the poppler-config.h, this is not going to be the best
way because the the name 'config.h' is way to common. So in that case, you may
want to rename both files (possibly the config.h as poppler-config.h and maybe
move the poppler-config.h into the poppler.h header?)

If you read this about AC_CONFIG_HEADERS()

http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_27.html

they show an example with two lines, but in the text they clearly talk about the
config file in singular: i.e. just one file. Though you can auto-generate
duplicates, people generally don't do that.

Also, if you never include config.h anywhere, then you clearly don't make use of
these #define! 8-) [it has been only a little over 1 year I really started to
learn about the configure tools... so I do not know everything, but this just
makes sense]

Again, before you turn down this specific entry, try to talk with some other
people about this. Look at other projects to see whether they have similar
setups. I'd be surprised if any would offer a config.h.in which wasn't generated
by autoreconf.

Thank you for looking into those!
Alexis
Comment 5 Kristian Høgsberg 2006-11-28 13:41:40 UTC
<tsdgeos> also have a look at https://bugs.freedesktop.org/show_bug.cgi?id=9139
please
<krh> there's is nothing wrong with generating multiple config files
<krh> and the poppler-config.h.in is indeed hand crafted to only expose a subset
of the config options
<krh> so that it is installable
<tsdgeos> that's what i thought
<tsdgeos> can you please answer him?
<krh> the problem when I first did this was that all public headerfiles would
include config.h and there was no way we could just install config.h
<krh> yeah, I'll just paste this
* genstef (n=stefan@gentoo/developer/genstef) has joined #poppler
<genstef> hi!
<tsdgeos> hi
<krh> also, config.h exposes a lot of symbols that we don't want as public API,
thus, the hand-crafted poppler-config.h.in
Comment 6 Albert Astals Cid 2011-06-19 14:59:31 UTC
Is this still needed?
Comment 7 Alexis Wilke 2011-06-19 16:23:27 UTC
Frankly, I have no clue. I have not been using anything like Poppler in a long while and now we've switched to Qt... plus, I mainly do work under Linux where everything works just fine. 8-)

Thank you for checking.
Alexis
Comment 8 Albert Astals Cid 2011-06-19 16:41:23 UTC
Closing as wontfix then until someone actually cares enough to post a new patch (if needed)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.