Menu
▾
▴
gnuplot-beta
|
From: Tatsuro M. <tma...@ya...> - 2010-03-09 00:15:17
|
Hello As for pdf file I have used it on the gnuplot web site, because I have not known 'make pdffigures'. Sorry my carelessness. I obey the Petr's decision that gnuplot for windows distribution includes wxt terminal. So please remove the below from Readme.windows. ************** Note that this package does not support the wxt terminal. If you would like to use the gnuplot with the wxt terminal, use gp440win32wxt-diff.zip to add the wxt terminal features. ************** And please add something like to 'Environmental variables' * Variable GNUTERM may be used to define the default terminal when gnuplot startup. `save` and `save set` commands. See 'help loadpath' for more details. Readme.Windows is revised by me from that in attached in gp440rc1_win.zip. (Explanation of gnuplot.exe is given by Petr, see http://old.nabble.com/gnuplot-4.4rc-1-%3A-ReadmeWindows-lacks-explanation-of-'gnuplot.exe'-td26569640.html#a26583638 ) Please revise Readme document the from technical and grammatical point of view. I have no confidence for my revising. Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Petr M. <mi...@ph...> - 2010-03-09 06:26:02
|
> I obey the Petr's decision that gnuplot for windows distribution includes wxt terminal. > So please remove the below from Readme.windows. > > ************** > Note that this package does not support the wxt terminal. If you would like > to use the gnuplot with the wxt terminal, use gp440win32wxt-diff.zip to add > the wxt terminal features. > ************** > > And please add something like to 'Environmental variables' > * Variable GNUTERM may be used to define the default terminal when gnuplot > startup. > `save` and `save set` commands. See 'help loadpath' for more details. Yes, that's exactly what I've also updated in README.Windows in the zip I've sent to Ethan for uploading. Petr |
|
From: Petr M. <mi...@ph...> - 2010-03-09 06:41:19
|
> As for pdf file I have used it on the gnuplot web site, because I have not > known 'make pdffigures'. But there is not yet gnuplot.pdf for 4.4 on the web. Maybe that's the reason for incomplete section for "help cairo" (those text I copied into my mail)? --- PM |
|
From: Tatsuro M. <tma...@ya...> - 2010-03-09 07:25:58
|
--- Petr Mikulik wrote: > > As for pdf file I have used it on the gnuplot web site, because I have not > > known 'make pdffigures'. > But there is not yet gnuplot.pdf for 4.4 on the web. Maybe that's the reason > for incomplete section for "help cairo" (those text I copied into my mail)? In http://www.gnuplot.info/documentation.html Official gnuplot online documentation The following official documentation is available online: Current 4.4/CVS Old There is gnuplot.pdf for 4.4/cvs. Perhaps it is old. I have tried make pdffigures on the cygwin system and upload it on the web http://www.tatsuromatsuoka.com/gnuplot/Eng/gp44/ 0005 TM_gnuplot.pdf This seem includes "help cairo". Regards Tatsuro > > --- > PM > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-09 07:31:32
|
On Monday 08 March 2010, Tatsuro MATSUOKA wrote: > > In > http://www.gnuplot.info/documentation.html > > Official gnuplot online documentation > The following official documentation is available online: > Current 4.4/CVS Old > > There is gnuplot.pdf for 4.4/cvs. Perhaps it is old. Yes, it is current: 5 March 2010 Following the release we will have to update all the web pages to say that 4.4 is "current" and 4.2 is "previous". > I have tried make pdffigures on the cygwin system and upload it on the web Don't worry about the pdf file. It is the same for all platforms, and I will upload a current one at the same time as the set of binaries and sources. |
|
From: Benjamin L. <lin...@gm...> - 2010-03-26 14:10:04
|
> I wonder about the pdf documentations. If I compile it by "make pdfimages", > I get a gnuplot.pdf of size 2.8 MB. Tatsuro obtained 2.1. If you create the pictures for the manual using the pdfcairp terminal, the resulting pdf images are larger than if you use the postscript terminal and use ghostscript to convert them to pdf. I dont't know if this is the case here, but it may be one explanation. benjamin |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2010-03-07 20:46:00
|
On Sunday 07 March 2010, Petr Mikulik wrote: > > > I have made those changes to INSTALL and the makefiles for mgw and cygwin. > > > I will also disable the HAVE_PWD_H option because > > > (1) Manfred Schwarb has reported here that it causes static build problems > > > (2) Daniel Loeb has reported on the newsgroup that it introduces privacy issues > > > (3) It seems like a totally unnecessary bell (or is it a whistle?) that in any case > > > is used only by the PostScript and PDF terminal output > > Well, now it seems that now it contains > SDict begin [ > /Author (mikulik) > instead of the previous > /Author (Petr Mikulik) > Is this intended? Shouldn't the /Author line be completely avoided? I don't know. There were two issues. The static build issue was caused by a call to getpwnam(), which is now gone. I suppose listing the user name is still an issue if you want complete anonymity, but it no longer includes GECOS information like phone number and address so I think it is not so much a privacy concern. |
|
From: Jonathan T. <jt...@as...> - 2010-03-07 22:23:20
|
On Sunday 07 March 2010, Petr Mikulik wrote:
[[about the postscript prologue]]
# Well, now it seems that now it contains
# SDict begin [
# /Author (mikulik)
# instead of the previous
# /Author (Petr Mikulik)
# Is this intended? Shouldn't the /Author line be completely avoided?
On Sun, 7 Mar 2010, sfeam (Ethan Merritt) wrote:
> I don't know.
> There were two issues.
>
> The static build issue was caused by a call to getpwnam(), which is now gone.
>
> I suppose listing the user name is still an issue if you want complete
> anonymity, but it no longer includes GECOS information like phone number
> and address so I think it is not so much a privacy concern.
I would rather omit the /Author line entirely (or make it explicitly
configurable via a user option "set identification" (or suchlike)).
--
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens
|
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-08 20:58:51
|
On Monday 08 March 2010 11:04:08 Petr Mikulik wrote: > I have compiled OS/2 binary package and synchronized it with Tatsuro's > build of Windows and dj2 packages. > > All of them are temporarily here: > physics.muni.cz/~mikulik/tmp/gp440.zip > Ethan, please upload the inner zip files to SourceForge. Could you please clarify? From your zip archive I retrieved 1440 -rw-r--r-- 1 merritt merritt 1468037 2010-03-08 10:32 gp440dj2.zip 3708 -rw-r--r-- 1 merritt merritt 3789129 2010-03-08 10:23 gp440os2.zip 1232 -rw-r--r-- 1 merritt merritt 1254841 2010-03-08 10:37 gp440win32x11.zip 10108 -rw-r--r-- 1 merritt merritt 10331008 2010-03-08 10:32 gp440win32.zip From Tatsuro's web site I have zip files 1460 -rw-r--r-- 1 merritt users 1489127 2010-03-07 21:53 gp440dj2.zip 4104 -rw-r--r-- 1 merritt users 4197789 2010-03-07 21:53 gp440win32wxt-diff.zip 1216 -rw-r--r-- 1 merritt users 1238908 2010-03-07 21:53 gp440win32x11.zip 7972 -rw-r--r-- 1 merritt users 8147492 2010-03-07 21:53 gp440win32.zip So they are different sizes. Which ones are correct to upload? > Considering Windows, I've put together the "native" Windows terminal with > the wxt version. Therefore, the default is the wxt terminal on Windows as on > Linux. I hope Copy-to-clipboard works; then only the Print dialog is missing > (and maybe user's configurable position&size of the graph windows). Do you mean that you combined gp440win32.zip and gp440win32wxt-diff.zip? Is that why your win32 zip file is bigger? (But your dj2 and winx11 files are also a different size). Maybe we should offer for download 2 versions, with and without wxt. Can I re-name yours to be gp440win32wxt, and keep Tatsuro's as gp440win32? Also, I need to label each file with a short description. Please check that I have this correctly: gp440win32.zip 8,147,492 bytes 2010-03-08 Windows binary package, no source gp440win32wxt.zip 10,331,008 bytes 2010-03-08 Windows binary package including wxt terminal, no source gp440win32x11.zip 1,238,908 bytes, 2010-03-08 Cygwin x11 binary package, no source, demos, or docs gp440dj2.zip 1,489,127 bytes, 2010-03-05 DJGPP binary package, no source, no docs gp440os2.zip 3,789,129 bytes, 2010-03-08 OS2 binary package, no source Ethan |
|
From: Petr M. <mi...@ph...> - 2010-03-08 21:37:53
|
> On Monday 08 March 2010 11:04:08 Petr Mikulik wrote: > > I have compiled OS/2 binary package and synchronized it with Tatsuro's > > build of Windows and dj2 packages. > > > > All of them are temporarily here: > > physics.muni.cz/~mikulik/tmp/gp440.zip > > Ethan, please upload the inner zip files to SourceForge. > > Could you please clarify? From your zip archive I retrieved > 1440 -rw-r--r-- 1 merritt merritt 1468037 2010-03-08 10:32 gp440dj2.zip > 3708 -rw-r--r-- 1 merritt merritt 3789129 2010-03-08 10:23 gp440os2.zip > 1232 -rw-r--r-- 1 merritt merritt 1254841 2010-03-08 10:37 gp440win32x11.zip > 10108 -rw-r--r-- 1 merritt merritt 10331008 2010-03-08 10:32 gp440win32.zip > > From Tatsuro's web site I have zip files > 1460 -rw-r--r-- 1 merritt users 1489127 2010-03-07 21:53 gp440dj2.zip > 4104 -rw-r--r-- 1 merritt users 4197789 2010-03-07 21:53 gp440win32wxt-diff.zip > 1216 -rw-r--r-- 1 merritt users 1238908 2010-03-07 21:53 gp440win32x11.zip > 7972 -rw-r--r-- 1 merritt users 8147492 2010-03-07 21:53 gp440win32.zip > > So they are different sizes. Which ones are correct to upload? > > > Considering Windows, I've put together the "native" Windows terminal with > > the wxt version. Therefore, the default is the wxt terminal on Windows as on > > Linux. I hope Copy-to-clipboard works; then only the Print dialog is missing > > (and maybe user's configurable position&size of the graph windows). > > Do you mean that you combined gp440win32.zip and gp440win32wxt-diff.zip? > Is that why your win32 zip file is bigger? Yes (let's don't let Windows users "patch" distribution). > (But your dj2 and winx11 files are also a different size). Yes, I did "unix2dos" for CR/LF, removed temporary exe from docs, and some other minor things, so that all what was in gp42*.zip is also in gp440*.zip. > Maybe we should offer for download 2 versions, with and without wxt. > Can I re-name yours to be gp440win32wxt, and keep Tatsuro's as gp440win32? I don't think it makes any sense or advantage. There are already wgnuplot.exe, wgnuplot_pipes.exe, pgnuplot.exe and gnuplot.exe in one zip, i.e. enough for user confusion. User gets the traditional windows terminal by "GNUTERM=windows", if needed. As on Linux, where this switch happened a year ago from x11 to wxt. For nostalgy, it could make sense to have a package with the static monolithic single file wgnuplot.exe as I was distributing it until now. (Would somebody need it? E.g. gp440win32small.zip?) > Also, I need to label each file with a short description. > > gp440win32.zip 8,147,492 bytes 2010-03-08 > Windows binary package, no source > > gp440win32wxt.zip 10,331,008 bytes 2010-03-08 > Windows binary package including wxt terminal, no source > > gp440win32x11.zip 1,238,908 bytes, 2010-03-08 > Cygwin x11 binary package, no source, demos, or docs > > gp440dj2.zip 1,489,127 bytes, 2010-03-05 > DJGPP binary package, no source, no docs > > gp440os2.zip 3,789,129 bytes, 2010-03-08 > OS2 binary package, no source I propose this: gp440win32.zip Windows binary package gp440win32x11.zip Windows binary package for Cygwin X11 (without docs and demos) gp440os2.zip OS/2 and eComStation binary package gp440dj2.zip DJGPP binary package (32bit DOS, for example) --- PM |
|
From: Petr M. <mi...@ph...> - 2010-03-09 06:48:48
|
One more minor thing: Tatsuro has added directory demo/html/ which is of no use. I've checked that "make" nor "webify" cannot work in the binary distribution (i.e. without full gnuplot sources) so it makes no sense to distribute this directory. I don't think there is anything useful for a user, right? Ethan, please remove directory demo/html/ from gp440win32.zip. --- PM |
|
From: Tatsuro M. <tma...@ya...> - 2010-03-09 07:06:39
|
Hello --- Petr Mikulik wrote: > One more minor thing: Tatsuro has added directory demo/html/ which is of no > use. I've checked that "make" nor "webify" cannot work in the binary > distribution (i.e. without full gnuplot sources) so it makes no sense to > distribute this directory. I don't think there is anything useful for a > user, right? > > Ethan, please remove directory demo/html/ from gp440win32.zip. Sorry, it requires make process. So contents in demo/html/ have no meaning for binary distribution. Please also remove demo/html/ from gp440dj2.zip. Regards Tatsuro -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Petr M. <mi...@ph...> - 2010-03-09 07:43:20
|
> > One more minor thing: Tatsuro has added directory demo/html/ which is of no > > use. I've checked that "make" nor "webify" cannot work in the binary > > distribution (i.e. without full gnuplot sources) so it makes no sense to > > distribute this directory. I don't think there is anything useful for a > > user, right? > > > > Ethan, please remove directory demo/html/ from gp440win32.zip. > > Sorry, it requires make process. So contents in demo/html/ have no meaning for binary distribution. > Please also remove demo/html/ from gp440dj2.zip. Oh, it is in DJ2 as well. Ethan, can you remove now or should I give you new package? Petr |
|
From: Manfred S. <man...@gm...> - 2010-03-05 14:52:49
|
>
> Although I think a 4.4.0 release is nearly ready, I have encountered
> a couple of last-minute glitches.
>
> 1) Sometime between the 4.4.0-rc1 tarball creation and the current
> 4.4 cvs, the targets "make clean" and "make distclean" have broken.
>
I noticed, too. "make mostlyclean" seems to work though.
Another thing: I recently did a static build, it was
a bit a pain. I had to manually set "#undef HAVE_PWD_H" and
had to apply
--- configure.in.orig 2010-03-01 13:44:59.000000000 +0100
+++ configure.in 2010-03-02 11:55:43.000000000 +0100
@@ -482,6 +482,7 @@
libgd_CPPFLAGS=`gdlib-config --cflags`
libgd_LDFLAGS=`gdlib-config --ldflags`
libgd_LIBS=`gdlib-config --libs`
+ libgd_LIBS="$libgd_LIBS -lexpat -pthread"
elif test -d "$with_gd"; then
libgd_CPPFLAGS="-I$with_gd/include"
libgd_LDFLAGS="-L$with_gd/lib"
Otherwise, gnuplot 4.4 works fine for me.
Thanks!
Manfred
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
|
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-05 17:44:34
|
On Friday 05 March 2010 06:52:39 Manfred Schwarb wrote: > > Another thing: I recently did a static build, it was > a bit a pain. I had to manually set "#undef HAVE_PWD_H" I don't see the connection there. What does HAVE_PWD_H have to do with a static build? There was a post on the newsgroup recently that implicitly complained about HAVE_PWD_H for privacy reasons. If there is now another down-side as well, I think we should get rid of this code. The only thing it does is fill in extra information in the "author" field of a PostScript or PDF file header. > and had to apply > > --- configure.in.orig 2010-03-01 13:44:59.000000000 +0100 > +++ configure.in 2010-03-02 11:55:43.000000000 +0100 > @@ -482,6 +482,7 @@ > libgd_CPPFLAGS=`gdlib-config --cflags` > libgd_LDFLAGS=`gdlib-config --ldflags` > libgd_LIBS=`gdlib-config --libs` > + libgd_LIBS="$libgd_LIBS -lexpat -pthread" > elif test -d "$with_gd"; then > libgd_CPPFLAGS="-I$with_gd/include" > libgd_LDFLAGS="-L$with_gd/lib" That seems like a problem with the libgd package configuration tool. I'll forward a bug report in that direction if I can confirm it. Ethan |
|
From: Manfred S. <man...@gm...> - 2010-03-05 22:05:22
|
> On Friday 05 March 2010 06:52:39 Manfred Schwarb wrote: > > > > Another thing: I recently did a static build, it was > > a bit a pain. I had to manually set "#undef HAVE_PWD_H" > > I don't see the connection there. > What does HAVE_PWD_H have to do with a static build? > I get the following when compiling with gcc 4.4.1: util.o: In function `getusername': /tmp/gnuplot-4.4/src/util.c:1211: warning: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking > There was a post on the newsgroup recently that implicitly complained > about HAVE_PWD_H for privacy reasons. If there is now another down-side > as well, I think we should get rid of this code. The only thing it does > is fill in extra information in the "author" field of a PostScript or > PDF file header. > > > > and had to apply > > > > --- configure.in.orig 2010-03-01 13:44:59.000000000 +0100 > > +++ configure.in 2010-03-02 11:55:43.000000000 +0100 > > @@ -482,6 +482,7 @@ > > libgd_CPPFLAGS=`gdlib-config --cflags` > > libgd_LDFLAGS=`gdlib-config --ldflags` > > libgd_LIBS=`gdlib-config --libs` > > + libgd_LIBS="$libgd_LIBS -lexpat -pthread" > > elif test -d "$with_gd"; then > > libgd_CPPFLAGS="-I$with_gd/include" > > libgd_LDFLAGS="-L$with_gd/lib" > > That seems like a problem with the libgd package configuration tool. > I'll forward a bug report in that direction if I can confirm it. > > Ethan -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-05 22:35:35
|
On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote: > > > and had to apply > > > > > > --- configure.in.orig 2010-03-01 13:44:59.000000000 +0100 > > > +++ configure.in 2010-03-02 11:55:43.000000000 +0100 > > > @@ -482,6 +482,7 @@ > > > libgd_CPPFLAGS=`gdlib-config --cflags` > > > libgd_LDFLAGS=`gdlib-config --ldflags` > > > libgd_LIBS=`gdlib-config --libs` > > > + libgd_LIBS="$libgd_LIBS -lexpat -pthread" > > > elif test -d "$with_gd"; then > > > libgd_CPPFLAGS="-I$with_gd/include" > > > libgd_LDFLAGS="-L$with_gd/lib" > > > > That seems like a problem with the libgd package configuration tool. > > I'll forward a bug report in that direction if I can confirm it. > > > > Ethan I can't reproduce this problem. On my machines, neither libgd nor gnuplot as a whole requires libexpat, which seems to be an XML parsing tool. And libpthread is pulled in by practically everything, so adding it specifically to libgd_LIBS is redundant. What was the error message you got before adding this line to configure.in? Ethan |
|
From: Tatsuro M. <tma...@ya...> - 2010-03-05 23:42:30
|
Hello On windows build (I have used the dynamic build), I do not use libexpat libraries. However, the libexpat-1.dll is required for gnuplot execution. I have looked around what requires libexpat. In the fontconfig.pc, I found *********** Libs.private: -L/devel/dist/win32/expat-2.0.1-1/lib -lexpat -L/devel/dist/win32/freetype-2.3.11-1/bin/../lib -lfreetype ********** For dynamic build, -lexpat is not required for linking but libexpat-1.dll is required for gnuplot execution because the libexpat is privately linked with from the fontconfig. Perhaps for static build, all libraries related might be required at link stage. If the gdlib-config requires the fontconfig, the libexpat might be required through the fontconfig for static build. The above is my guess so that please see it as a reference. Regards Tatsuro --- Ethan Merritt wrote: > On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote: > > > > and had to apply > > > > > > > > --- configure.in.orig 2010-03-01 13:44:59.000000000 +0100 > > > > +++ configure.in 2010-03-02 11:55:43.000000000 +0100 > > > > @@ -482,6 +482,7 @@ > > > > libgd_CPPFLAGS=`gdlib-config --cflags` > > > > libgd_LDFLAGS=`gdlib-config --ldflags` > > > > libgd_LIBS=`gdlib-config --libs` > > > > + libgd_LIBS="$libgd_LIBS -lexpat -pthread" > > > > elif test -d "$with_gd"; then > > > > libgd_CPPFLAGS="-I$with_gd/include" > > > > libgd_LDFLAGS="-L$with_gd/lib" > > > > > > That seems like a problem with the libgd package configuration tool. > > > I'll forward a bug report in that direction if I can confirm it. > > > > > > Ethan > > I can't reproduce this problem. > > On my machines, neither libgd nor gnuplot as a whole requires libexpat, > which seems to be an XML parsing tool. > > And libpthread is pulled in by practically everything, so adding it > specifically to libgd_LIBS is redundant. > > What was the error message you got before adding this line to configure.in? > > Ethan > > ------------------------------------------------------------------------------ > Download Intel¢î Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -------------------------------------- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ |
|
From: Manfred S. <man...@gm...> - 2010-03-05 23:51:01
|
> On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote:
> > > > and had to apply
> > > >
> > > > --- configure.in.orig 2010-03-01 13:44:59.000000000 +0100
> > > > +++ configure.in 2010-03-02 11:55:43.000000000 +0100
> > > > @@ -482,6 +482,7 @@
> > > > libgd_CPPFLAGS=`gdlib-config --cflags`
> > > > libgd_LDFLAGS=`gdlib-config --ldflags`
> > > > libgd_LIBS=`gdlib-config --libs`
> > > > + libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> > > > elif test -d "$with_gd"; then
> > > > libgd_CPPFLAGS="-I$with_gd/include"
> > > > libgd_LDFLAGS="-L$with_gd/lib"
> > >
> > > That seems like a problem with the libgd package configuration tool.
> > > I'll forward a bug report in that direction if I can confirm it.
> > >
> > > Ethan
>
> I can't reproduce this problem.
>
> On my machines, neither libgd nor gnuplot as a whole requires libexpat,
> which seems to be an XML parsing tool.
>
I think it comes from libfontconfig, newer libgd versions use it
(I use some cvs version of libgd 2.0.36 at the moment):
# ldd /usr/lib64/libfontconfig.so
linux-vdso.so.1 => (0x00007fc1d544d000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc1d4f90000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fc1d4d66000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc1d4a0b000)
libz.so.1 => /lib64/libz.so.1 (0x00007fc1d47f5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc1d544e000)
# ldd /usr/local/lib/libgd.so
linux-vdso.so.1 => (0x00007fff9caea000)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fa27ef78000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fa27ed42000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa27eabc000)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fa27e894000)
libz.so.1 => /lib64/libz.so.1 (0x00007fa27e67d000)
libm.so.6 => /lib64/libm.so.6 (0x00007fa27e428000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa27e0cd000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa27dea3000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa27f3e7000)
But "gdlib-config --libs" gives:
-ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm
So it seems libgd does not add all needed libraries to gdlib-config.
> And libpthread is pulled in by practically everything, so adding it
> specifically to libgd_LIBS is redundant.
>
> What was the error message you got before adding this line to
> configure.in?
>
from config.log:
configure:11686: checking for gdImageStringFT in -lgd
configure:11721: gcc -o conftest -g -O2 -I/usr/local/include -static -s -L/usr/local/lib -L/usr/lib64 -L/lib conftest.c -lgd -lm -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -lfreetype >&5
/usr/local/lib/libgd.a(gdft.o): In function `gdFontCacheSetup':
/tmp/libgd/gd-libgd-20/gdft.c:826: undefined reference to `pthread_mutex_init'
/tmp/libgd/gd-libgd-20/gdft.c:829: undefined reference to `pthread_mutex_destroy'
...
/usr/lib64/libfontconfig.a(fcxml.o): In function `FcConfigMessage':
/tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:476: undefined reference to `XML_GetCurrentLineNumber'
/tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:479: undefined reference to `XML_GetCurrentLineNumber'
...
Cheers, Manfred
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
|
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-06 00:28:50
|
On Friday 05 March 2010 15:50:48 Manfred Schwarb wrote:
>
> > On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote:
> > > > > and had to apply
> > > > >
> > > > > --- configure.in.orig 2010-03-01 13:44:59.000000000 +0100
> > > > > +++ configure.in 2010-03-02 11:55:43.000000000 +0100
> > > > > @@ -482,6 +482,7 @@
> > > > > libgd_CPPFLAGS=`gdlib-config --cflags`
> > > > > libgd_LDFLAGS=`gdlib-config --ldflags`
> > > > > libgd_LIBS=`gdlib-config --libs`
> > > > > + libgd_LIBS="$libgd_LIBS -lexpat -pthread"
> > > > > elif test -d "$with_gd"; then
> > > > > libgd_CPPFLAGS="-I$with_gd/include"
> > > > > libgd_LDFLAGS="-L$with_gd/lib"
> > > >
> > > > That seems like a problem with the libgd package configuration tool.
> > > > I'll forward a bug report in that direction if I can confirm it.
> > > >
> > > > Ethan
> >
> > I can't reproduce this problem.
> >
> > On my machines, neither libgd nor gnuplot as a whole requires libexpat,
> > which seems to be an XML parsing tool.
> >
>
> I think it comes from libfontconfig, newer libgd versions use it
> (I use some cvs version of libgd 2.0.36 at the moment):
>
> # ldd /usr/lib64/libfontconfig.so
> linux-vdso.so.1 => (0x00007fc1d544d000)
> libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc1d4f90000)
> libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fc1d4d66000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fc1d4a0b000)
> libz.so.1 => /lib64/libz.so.1 (0x00007fc1d47f5000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fc1d544e000)
>
> # ldd /usr/local/lib/libgd.so
> linux-vdso.so.1 => (0x00007fff9caea000)
> libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fa27ef78000)
> libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fa27ed42000)
> libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa27eabc000)
> libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fa27e894000)
> libz.so.1 => /lib64/libz.so.1 (0x00007fa27e67d000)
> libm.so.6 => /lib64/libm.so.6 (0x00007fa27e428000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fa27e0cd000)
> libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa27dea3000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fa27f3e7000)
Huh. I also am using libgd 2.0.36, built from source.
It does link to libfreetype and to libfontconfig, but nowhere in the chain
is there a dependence on libexpat:
stonelion [3] ldd /home/local/src/gd-2.0.36/.libs/libgd.so.2
linux-gate.so.1 => (0xffffe000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7851000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb771f000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb76fc000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb76c8000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7644000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7619000)
libz.so.1 => /lib/libz.so.1 (0xb7606000)
libm.so.6 => /lib/i686/libm.so.6 (0xb75de000)
libc.so.6 => /lib/i686/libc.so.6 (0xb747d000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb745f000)
libdl.so.2 => /lib/libdl.so.2 (0xb7459000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7318000)
/lib/ld-linux.so.2 (0xb78c0000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7314000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb730d000)
stonelion [4] ldd /usr/lib/libfontconfig.so.1
linux-gate.so.1 => (0xffffe000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb762e000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb74ed000)
libc.so.6 => /lib/i686/libc.so.6 (0xb738c000)
libz.so.1 => /lib/libz.so.1 (0xb7379000)
libdl.so.2 => /lib/libdl.so.2 (0xb7373000)
libm.so.6 => /lib/i686/libm.so.6 (0xb734b000)
/lib/ld-linux.so.2 (0xb7700000)
stonelion [5] ldd /usr/lib/libxml2.so.2
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/libdl.so.2 (0xb7637000)
libz.so.1 => /lib/libz.so.1 (0xb7624000)
libm.so.6 => /lib/i686/libm.so.6 (0xb75fc000)
libc.so.6 => /lib/i686/libc.so.6 (0xb749b000)
/lib/ld-linux.so.2 (0xb7798000)
stonelion [6] ldd /usr/lib/libfreetype.so.6
linux-gate.so.1 => (0xffffe000)
libz.so.1 => /lib/libz.so.1 (0xb7762000)
libc.so.6 => /lib/i686/libc.so.6 (0xb7601000)
/lib/ld-linux.so.2 (0xb7813000)
So I certainly believe you that your machine is trying to pull in
libexpat, but I don't know where/why this dependency creeps in.
One of life's little mysteries :-)
cheers,
Ethan
>
> But "gdlib-config --libs" gives:
> -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm
>
> So it seems libgd does not add all needed libraries to gdlib-config.
>
>
> > And libpthread is pulled in by practically everything, so adding it
> > specifically to libgd_LIBS is redundant.
> >
> > What was the error message you got before adding this line to
> > configure.in?
> >
>
>
> from config.log:
> configure:11686: checking for gdImageStringFT in -lgd
> configure:11721: gcc -o conftest -g -O2 -I/usr/local/include -static -s -L/usr/local/lib -L/usr/lib64 -L/lib conftest.c -lgd -lm -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -lfreetype >&5
> /usr/local/lib/libgd.a(gdft.o): In function `gdFontCacheSetup':
> /tmp/libgd/gd-libgd-20/gdft.c:826: undefined reference to `pthread_mutex_init'
> /tmp/libgd/gd-libgd-20/gdft.c:829: undefined reference to `pthread_mutex_destroy'
> ...
> /usr/lib64/libfontconfig.a(fcxml.o): In function `FcConfigMessage':
> /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:476: undefined reference to `XML_GetCurrentLineNumber'
> /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:479: undefined reference to `XML_GetCurrentLineNumber'
> ...
>
>
> Cheers, Manfred
|
|
From: Manfred S. <man...@gm...> - 2010-03-06 12:29:09
|
Am Freitag, den 05.03.2010, 16:25 -0800 schrieb Ethan Merritt: > On Friday 05 March 2010 15:50:48 Manfred Schwarb wrote: > > > > > On Friday 05 March 2010 14:05:14 Manfred Schwarb wrote: > > > > > > and had to apply > > > > > > > > > > > > --- configure.in.orig 2010-03-01 13:44:59.000000000 +0100 > > > > > > +++ configure.in 2010-03-02 11:55:43.000000000 +0100 > > > > > > @@ -482,6 +482,7 @@ > > > > > > libgd_CPPFLAGS=`gdlib-config --cflags` > > > > > > libgd_LDFLAGS=`gdlib-config --ldflags` > > > > > > libgd_LIBS=`gdlib-config --libs` > > > > > > + libgd_LIBS="$libgd_LIBS -lexpat -pthread" > > > > > > elif test -d "$with_gd"; then > > > > > > libgd_CPPFLAGS="-I$with_gd/include" > > > > > > libgd_LDFLAGS="-L$with_gd/lib" > > > > > > > > > > That seems like a problem with the libgd package configuration tool. > > > > > I'll forward a bug report in that direction if I can confirm it. > > > > > > > > > > Ethan > > > > > > I can't reproduce this problem. > > > > > > On my machines, neither libgd nor gnuplot as a whole requires libexpat, > > > which seems to be an XML parsing tool. > > > > > > > I think it comes from libfontconfig, newer libgd versions use it > > (I use some cvs version of libgd 2.0.36 at the moment): > > > > # ldd /usr/lib64/libfontconfig.so > > linux-vdso.so.1 => (0x00007fc1d544d000) > > libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fc1d4f90000) > > libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fc1d4d66000) > > libc.so.6 => /lib64/libc.so.6 (0x00007fc1d4a0b000) > > libz.so.1 => /lib64/libz.so.1 (0x00007fc1d47f5000) > > /lib64/ld-linux-x86-64.so.2 (0x00007fc1d544e000) > > > > # ldd /usr/local/lib/libgd.so > > linux-vdso.so.1 => (0x00007fff9caea000) > > libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fa27ef78000) > > libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fa27ed42000) > > libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa27eabc000) > > libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fa27e894000) > > libz.so.1 => /lib64/libz.so.1 (0x00007fa27e67d000) > > libm.so.6 => /lib64/libm.so.6 (0x00007fa27e428000) > > libc.so.6 => /lib64/libc.so.6 (0x00007fa27e0cd000) > > libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fa27dea3000) > > /lib64/ld-linux-x86-64.so.2 (0x00007fa27f3e7000) > > Huh. I also am using libgd 2.0.36, built from source. > It does link to libfreetype and to libfontconfig, but nowhere in the chain > is there a dependence on libexpat: > > stonelion [3] ldd /home/local/src/gd-2.0.36/.libs/libgd.so.2 > linux-gate.so.1 => (0xffffe000) > libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7851000) > libX11.so.6 => /usr/lib/libX11.so.6 (0xb771f000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb76fc000) > libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb76c8000) > libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7644000) > libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7619000) > libz.so.1 => /lib/libz.so.1 (0xb7606000) > libm.so.6 => /lib/i686/libm.so.6 (0xb75de000) > libc.so.6 => /lib/i686/libc.so.6 (0xb747d000) > libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb745f000) > libdl.so.2 => /lib/libdl.so.2 (0xb7459000) > libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7318000) > /lib/ld-linux.so.2 (0xb78c0000) > libXau.so.6 => /usr/lib/libXau.so.6 (0xb7314000) > libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb730d000) > stonelion [4] ldd /usr/lib/libfontconfig.so.1 > linux-gate.so.1 => (0xffffe000) > libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb762e000) > libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb74ed000) > libc.so.6 => /lib/i686/libc.so.6 (0xb738c000) > libz.so.1 => /lib/libz.so.1 (0xb7379000) > libdl.so.2 => /lib/libdl.so.2 (0xb7373000) > libm.so.6 => /lib/i686/libm.so.6 (0xb734b000) > /lib/ld-linux.so.2 (0xb7700000) > stonelion [5] ldd /usr/lib/libxml2.so.2 > linux-gate.so.1 => (0xffffe000) > libdl.so.2 => /lib/libdl.so.2 (0xb7637000) > libz.so.1 => /lib/libz.so.1 (0xb7624000) > libm.so.6 => /lib/i686/libm.so.6 (0xb75fc000) > libc.so.6 => /lib/i686/libc.so.6 (0xb749b000) > /lib/ld-linux.so.2 (0xb7798000) > stonelion [6] ldd /usr/lib/libfreetype.so.6 > linux-gate.so.1 => (0xffffe000) > libz.so.1 => /lib/libz.so.1 (0xb7762000) > libc.so.6 => /lib/i686/libc.so.6 (0xb7601000) > /lib/ld-linux.so.2 (0xb7813000) > > So I certainly believe you that your machine is trying to pull in > libexpat, but I don't know where/why this dependency creeps in. > One of life's little mysteries :-) > I did some digging, it seems you can build libfontconfig either with libexpat or with libxml2, at your will. My distribution (OpenSuse) decided to build libfontconfig with "configure --enable-libxml2=no", so that libexpat is used. No idea why they did like this. What is your "gdlib-config --libs" output? Does it mention "-lxml2"? So then only the libexpat case would be broken. For the pthreads thing, perhaps this is dependent on the glibc and/or gcc used, in my case it is glibc 2.10.1 and gcc 4.4.1. Manfred > cheers, > Ethan > > > > > > > But "gdlib-config --libs" gives: > > -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm > > > > So it seems libgd does not add all needed libraries to gdlib-config. > > > > > > > And libpthread is pulled in by practically everything, so adding it > > > specifically to libgd_LIBS is redundant. > > > > > > What was the error message you got before adding this line to > > > configure.in? > > > > > > > > > from config.log: > > configure:11686: checking for gdImageStringFT in -lgd > > configure:11721: gcc -o conftest -g -O2 -I/usr/local/include -static -s -L/usr/local/lib -L/usr/lib64 -L/lib conftest.c -lgd -lm -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm -ljpeg -lfreetype >&5 > > /usr/local/lib/libgd.a(gdft.o): In function `gdFontCacheSetup': > > /tmp/libgd/gd-libgd-20/gdft.c:826: undefined reference to `pthread_mutex_init' > > /tmp/libgd/gd-libgd-20/gdft.c:829: undefined reference to `pthread_mutex_destroy' > > ... > > /usr/lib64/libfontconfig.a(fcxml.o): In function `FcConfigMessage': > > /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:476: undefined reference to `XML_GetCurrentLineNumber' > > /tmp/fontconfig-2.7.0/fontconfig-2.7.0/src/fcxml.c:479: undefined reference to `XML_GetCurrentLineNumber' > > ... > > > > > > Cheers, Manfred |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-03-06 17:27:49
|
On Saturday 06 March 2010, Manfred Schwarb wrote: > > So I certainly believe you that your machine is trying to pull in > > libexpat, but I don't know where/why this dependency creeps in. > > One of life's little mysteries :-) > > > > I did some digging, it seems you can build libfontconfig either with > libexpat or with libxml2, at your will. > My distribution (OpenSuse) decided to build libfontconfig with > "configure --enable-libxml2=no", so that libexpat is used. > No idea why they did like this. > > What is your "gdlib-config --libs" output? Does it mention "-lxml2"? > So then only the libexpat case would be broken. > stonelion [386] gdlib-config --libs -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm |
