matplotlib is reading old system headers, in preference to Sage ones.
Dr. David Kirkby
BUILDING MATPLOTLIB
matplotlib: 0.99.1
python: 2.6.4 (r264:75706, Jun 5 2010, 17:43:53) [GCC
4.4.1]
platform: sunos5
REQUIRED DEPENDENCIES
numpy: 1.3.0
freetype2: 9.8.3
That version of freetype is not the one in Sage.
when matplot libs starts building with gcc, I see:
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API
-I/rootpool2/local/kirkby/sage-4.4.3/local/lib/python2.6/site-packages/numpy/core/include
-I/usr/sfw/include -I/usr/sfw/include/freetype2 -I/usr/local/include -I.
-I/rootpool2/local/kirkby/sage-4.4.3/local/include/
-I/rootpool2/local/kirkby/sage-4.4.3/local/include/python2.6 -c src/ft2font.cpp
-o build/temp.solaris-2.10-sun4v-2.6/src/ft2font.o
Note how the include path has some directories like -I/usr/sfw/include and
-I/usr/local/include before the Sage directory
-I/rootpool2/local/kirkby/sage-4.4.3/local/include/
Therefore old versions of include files are being included.
There's a warnings given later
In file included from /usr/sfw/include/freetype2/freetype/freetype.h:51,
from src/ft2font.h:14,
from src/ft2font.cpp:1:
/usr/sfw/include/freetype2/freetype/config/ftconfig.h:65:1: warning:
"SIZEOF_LONG" redefined
The problem is, we do not want Sage including those files, but rather those in
Sage.
I don't know exactly what is happening, but it may be that the configuration file
/usr/sfw/bin/freetype-config
is found before $SAGE_LOCAL/bin/freetype-config, so the locations of the include
directories from there are used.
This all looks wrong to me.
Comments?
Dave
Ondrej Certik
I vaguely remember having these problems with matplotlib before (I had
broken freetype installed on some server and it failed to build) and
actually fixing the spkg package in Sage for that. So I guess more
work is needed.
Ondrej
Dr. David Kirkby
Thank you. I noticed on package (Singular) where CPPFLAGS was not set to
$SAGE_LOCAL/include, and doing so ensured the include files in Sage were found.
I've not tried this with Matplotlib, but it might be a way to work around the
problem if there is no configure option to specify the location of freetype.
Dave
John Hunter
The mpl configure happens in setupext.py that lives next to setup.py.
It tries to use pkgconfig if it is available to find freetype, so you
may have luck setting your PKG_CONFIG_PATH if you are using it.
Alternatively, there is a dictionary in setupext.py called basedirs
that maps platform to list of directories to search for support libs.
You might want to modify the defaults to find the directory containing
the sage supplied versions.
JDH
Dr. David Kirkby
> On Wed, Jun 9, 2010 at 9:25 AM, Dr. David Kirkby
> <david....@onetel.net> wrote:
>
>> Thank you. I noticed on package (Singular) where CPPFLAGS was not set to
>> $SAGE_LOCAL/include, and doing so ensured the include files in Sage were
>> found. I've not tried this with Matplotlib, but it might be a way to work
>> around the problem if there is no configure option to specify the location
>> of freetype.
>
> The mpl configure happens in setupext.py that lives next to setup.py.
> It tries to use pkgconfig if it is available to find freetype, so you
> may have luck setting your PKG_CONFIG_PATH if you are using it.
I was not using PKG_CONFIG_PATH
Would it be a good idea in general to set PKG_CONFIG_PATH to a directory in
Sage? I'm not sure if it would need to be $SAGE_LOCAL, $SAGE_LOCAL/lib, or
$SAGE_LOCAL/lib/pkgconfig.
I would have thought that it sensible to prepend the required Sage directory to
PKG_CONFIG_PATH, in much the same way as $SAGE_LOCAL/bin is prepended to PATH
and $SAGE_LOCAL/lib is prepended to LD_LIBRARY_PATH. At the moment, that is not
happening in Sage, despite there being several configuration files in the
directory $SAGE_LOCAL/lib/pkgconfig.
What I can't understand is how /usr/sfw/include/freetype2 was found though.
There was certainly no PKG_CONFIG_PATH set to anything like /usr/sfw, though
/usr/sfw/bin was in my path, and there is a directory /usr/sfw/lib/pkgconfig
So how did matplotlib find the freetype headers in /usr/sfw/include?
There is a file /usr/sfw/bin/freetype-config which I thought might have been the
culprit.
> Alternatively, there is a dictionary in setupext.py called basedirs
> that maps platform to list of directories to search for support libs.
> You might want to modify the defaults to find the directory containing
> the sage supplied versions.
>
> JDH
At the moment, setupext.py is patched in Sage to:
sage_inc = os.environ['SAGE_LOCAL'] + '/include/'
sage_lib = os.environ['SAGE_LOCAL'] + '/lib/'
basedir = {
'win32' : ['win32_static',],
'linux2' : [sage_lib],
'linux' : ['/usr/local', '/usr',],
'cygwin' : ['/usr/local', '/usr',],
'_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/local',
'/usr', '/sw'],
# it appears builds with darwin are broken because of all the
# different flags the deps can be compile with, so I am pushing
# people to :
# make -f make.osx fetch deps mpl_build mpl_install
'darwin' : [sage_lib],
'freebsd4' : ['/usr/local', '/usr'],
'freebsd5' : ['/usr/local', '/usr'],
'freebsd6' : ['/usr/local', '/usr'],
'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
'gnukfreebsd5' : ['/usr/local', '/usr'],
'gnukfreebsd6' : ['/usr/local', '/usr'],
'aix5' : ['/usr/local'],
}
So sage_lib is used on linux, but not Solaris. Does that make any sense even on
Linux - forget Solaris for a minute? Given all the other directories in the
'basedir' list do *not* end in "lib", I can't see why the one for Linux should
have substiuted $SAGE_LOCAL/lib. It would seem more logical for it to be
$SAGE_LOCAL and not $SAGE_LOCAL/lib.
Anyway, given all the above, what would seem most logical to put on that
'sunos5' line, which is the one that is relevant here, since that is what python
is indicating.
drkirkby@hawk:~$ python
Python 2.6.4 (r264:75706, Feb 14 2010, 14:03:47) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.platform
'sunos5'
>>>
Dave
John Hunter
<david....@onetel.net> wrote:
>> The mpl configure happens in setupext.py that lives next to setup.py.
>> It tries to use pkgconfig if it is available to find freetype, so you
>> may have luck setting your PKG_CONFIG_PATH if you are using it.
>
> I was not using PKG_CONFIG_PATH
What I am suggesting is that you might want to.
> Would it be a good idea in general to set PKG_CONFIG_PATH to a directory in
> Sage? I'm not sure if it would need to be $SAGE_LOCAL, $SAGE_LOCAL/lib, or
> $SAGE_LOCAL/lib/pkgconfig.
It should be set to the subdir that includes the *.pc files, most
likely $SAGE_LOCAL/lib/pkgconfig from the candidates above.
> I would have thought that it sensible to prepend the required Sage directory
> to PKG_CONFIG_PATH, in much the same way as $SAGE_LOCAL/bin is prepended to
> PATH and $SAGE_LOCAL/lib is prepended to LD_LIBRARY_PATH. At the moment,
> that is not happening in Sage, despite there being several configuration
> files in the directory $SAGE_LOCAL/lib/pkgconfig.
If $SAGE_LOCAL/lib/pkgconfigs has *.pc fles in it, prepending this dir
to your PKG_CONFIG_PATH env var, or setting PKG_CONFIG_PATH to it if
it is not otherwise defined, is certainly a good idea vis-a-vid mpl,
because we do rely on pkg-config if it is available.
> What I can't understand is how /usr/sfw/include/freetype2 was found though.
> There was certainly no PKG_CONFIG_PATH set to anything like /usr/sfw, though
> /usr/sfw/bin was in my path, and there is a directory /usr/sfw/lib/pkgconfig
>
> So how did matplotlib find the freetype headers in /usr/sfw/include?
This is strange given that you are patching basedir as you indicated
below. The only things I can think of are:
* sys.platform != 'darwin' on the box you are building on. In this
case you need to modify your patch to include sys.platform. This is
the most likely culprit as far as I can see.
* something about your build environment is not clean...
* PKG_CONFIG_PATH is somehow set in your build env and includes the sfw tree
JDH
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
John Hunter
> * sys.platform != 'darwin' on the box you are building on. In this
> case you need to modify your patch to include sys.platform. This is
> the most likely culprit as far as I can see.
Sorry, upon rereading your post, I see you are building on a solaris
platform and not an OSX platform. It does look like you need an entry
in basedir that maps your solaris sys.platform -> [sage_lib].
Presumably this is 'sunos5'.
JDH
David Kirkby
Hi, thank you for the suggestions here.
There is a directory in sage with .pc files. It is
local/lib/pkgconfig, which includes the file
./local/lib/pkgconfig/freetype2.pc, which has in it
drkirkby@redstart:~/32/sage-4.4.3$ cat ./local/lib/pkgconfig/freetype2.pc
prefix=/export/home/drkirkby/32/sage-4.4.3/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: FreeType 2
Description: A free, high-quality, and portable font engine.
Version: 9.16.3
Requires:
Libs: -L${libdir} -lfreetype -lz
Cflags: -I${includedir}/freetype2 -I${includedir}
It would seem from the information you provided that Sage should be
setting PKG_CONFIG_PATH to $SAGE_LOCAL/lib/pkgconfig, which it is
*not* doing. I could obviously set that on my machine, but that is
hardly the point. Others could get this problem too. This looks like
something that should be set globally for all Sage users.
On the machine I find
drkirkby@redstart:~$ /usr/bin/pkg-config --modversion --cflags --libs freetype2
9.7.3
-I/usr/sfw/include/freetype2 -R/usr/sfw/lib -L/usr/sfw/lib -lfreetype
so that explains I think why matplotlib is finding freetpe2 version
9.7.3 and not the version in Sage.
It seems rather odd, but the version of freetype2 on my machine in
/usr/sfw is 9.7.3, whereas Sage includes version 2.3.5 and the
current version is 2.3.15. How I can have a larger version number than
the latest from the freetype web site on a 5-year old distribution of
Solaris is rather odd, but that seems to be the case
drkirkby@redstart:~$ cat /usr/lib/pkgconfig/freetype2.pc
prefix=/usr/sfw
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: FreeType 2
Description: A free, high-quality, and portable font engine.
Version: 9.7.3
Requires:
Libs: -L${libdir} -R${libdir} -lfreetype
Cflags: -I${includedir}/freetype2
Perhaps that file has an error in it, or perhaps freetype2 at one
point decided to change their version numbering in a rather odd way,
going backwards!
I've tried the following - none of which avoid matplotlib finding the
version of freetype on my system and not the one in Sage.
1) $ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/pkgconfig
2) Edit setupext.py and set
basedir = {
...
'sunos5' : [sage_lib],
...
}
3) Create a new variable
sage_local = os.environ['SAGE_LOCAL']
then edit setupext.p to say
basedir = {
...
'sunos5' : [sage_local],
...
}
Any other ideas?
Dr. David Kirkby
> I've tried the following - none of which avoid matplotlib finding the
> version of freetype on my system and not the one in Sage.
>
> 1) $ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/pkgconfig
Actually, that should have been
PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig
but it does not help the situation.
This issue is not specific to Solaris either. On sage.math (linux), the install
shows:
freetype2: 9.16.3
which is what is shown by
kirkby@sage:~$ /usr/bin/pkg-config --modversion freetype2
9.16.3
So it looks to me like the presence of pkg-config on a system is forcing
matplotlib to use that version of freetype and ignore the one which is shipped
with Sage. That can't be desirable, but how to fix it is less than clear to me.
The *only* way I have found so far to avoid matplotlib finding the old version
of freetype2, is to change the permissions on pkg-config so it can't be
executed. That needs root access of course. Then Sage reports it finds
freetype2, but does not know the version. It would appear to me at that point
that it probably finds the one shipped with Sage.
I thought the high version number of freetype2 on Solaris might have been a
mistake, but it is similar on sage.math too. There's something I'm not
understanding here.
Dave
Willem Jan Palenstijn
> drkirkby@redstart:~$ cat /usr/lib/pkgconfig/freetype2.pc
> prefix=/usr/sfw
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
>
> Name: FreeType 2
> Description: A free, high-quality, and portable font engine.
> Version: 9.7.3
> Requires:
> Libs: -L${libdir} -R${libdir} -lfreetype
> Cflags: -I${includedir}/freetype2
>
> Perhaps that file has an error in it, or perhaps freetype2 at one
> point decided to change their version numbering in a rather odd way,
> going backwards!
Freetype just has a couple of different versioning schemes. The version number
"9.7.3" in the .pc file corresponds to release 2.1.9, and "9.16.3" corresponds
to release 2.3.5. (And then there's the numbering scheme which it uses for its
.so versions, which is different yet again.)
See the file src/docs/VERSION.DLL in the freetype package for details.
-Willem Jan
Dr. David Kirkby
Thank you. Having read src/docs/VERSION.DLL, I see that there are in fact
*three* different numbers all associated with the version. It is any wonder I've
been confused?
Dave
release libtool so
-------------------------------
2.3.12 10.0.4 6.4.0
2.3.11 9.22.3 6.3.22
2.3.10 9.21.3 6.3.21
2.3.9 9.20.3 6.3.20
2.3.8 9.19.3 6.3.19
2.3.7 9.18.3 6.3.18
2.3.6 9.17.3 6.3.17
2.3.5 9.16.3 6.3.16
2.3.4 9.15.3 6.3.15
2.3.3 9.14.3 6.3.14
2.3.2 9.13.3 6.3.13
2.3.1 9.12.3 6.3.12
2.3.0 9.11.3 6.3.11
2.2.1 9.10.3 6.3.10
2.2.0 9.9.3 6.3.9
2.1.10 9.8.3 6.3.8
2.1.9 9.7.3 6.3.7
2.1.8 9.6.3 6.3.6
2.1.7 9.5.3 6.3.5
2.1.6 9.5.3 6.3.5
2.1.5 9.4.3 6.3.4
2.1.4 9.3.3 6.3.3
2.1.3 9.2.3 6.3.2
2.1.2 9.1.3 6.3.1
2.1.1 9.0.3 ?
2.1.0 8.0.2 ?
2.0.9 9.0.3 ?
2.0.8 8.0.2 ?
2.0.4 7.0.1 ?
2.0.1 6.1.0 ?
Jason Grout
> Thank you. Having read src/docs/VERSION.DLL, I see that there are in
> fact *three* different numbers all associated with the version. It is
> any wonder I've been confused?
>
Now *I'm* confused :). What is the conclusion? Does anything need to
be done?
I'm in the process of updating matplotlib in Sage to 0.99.3 to get a
needed bugfix into the Sage version. David: are you working on the spkg
too?
Thanks,
Jason
--
Jason Grout
Jason Grout
Yes. Currently, the patched setupext.py file looks like:
---------------------------------
### FOR SAGE
sage_inc = os.environ['SAGE_LOCAL'] + '/include/'
sage_lib = os.environ['SAGE_LOCAL'] + '/lib/'
basedir = {
'win32' : ['win32_static',],
'linux2' : [sage_lib],
'linux' : ['/usr/local', '/usr',],
'cygwin' : ['/usr/local', '/usr',],
'_darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219', '/usr/local',
'/usr', '/sw'],
# it appears builds with darwin are broken because of all the
# different flags the deps can be compile with, so I am pushing
# people to :
# make -f make.osx fetch deps mpl_build mpl_install
'darwin' : [sage_lib],
'freebsd4' : ['/usr/local', '/usr'],
'freebsd5' : ['/usr/local', '/usr'],
'freebsd6' : ['/usr/local', '/usr'],
'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
'gnukfreebsd5' : ['/usr/local', '/usr'],
'gnukfreebsd6' : ['/usr/local', '/usr'],
'aix5' : ['/usr/local'],
}
---------------------------------
AND there's another patch, where basedir is actually used:
-------------------------------
def add_base_flags(module):
incdirs = filter(os.path.exists,
[os.path.join(p, 'include') for p in
basedir[sys.platform] ])
libdirs = filter(os.path.exists,
[os.path.join(p, 'lib') for p in
basedir[sys.platform] ]+
[os.path.join(p, 'lib64') for p in
basedir[sys.platform] ] )
module.include_dirs.extend(incdirs)
module.include_dirs.append('.')
module.include_dirs.append(sage_inc)
module.library_dirs.extend(libdirs)
module.library_dirs.extend([sage_lib])
---------------------------------
(note that we added sage_inc and sage_lib *after* the platform specific
directories) (and we confusingly use append and extend---minor nitpick,
though).
So my guess is that sunos5 is getting set in the basedirs definition,
and then the sage-specific directories are then getting appended after
the platform-specific directories in the second piece of code above.
What if we merely change the second piece of code to be:
---------------------------------
def add_base_flags(module):
module.include_dirs.append(os.environ['SAGE_LOCAL'] + '/include/')
module.library_dirs.append(os.environ['SAGE_LOCAL'] + '/lib/')
incdirs = filter(os.path.exists,
[os.path.join(p, 'include') for p in
basedir[sys.platform] ])
libdirs = filter(os.path.exists,
[os.path.join(p, 'lib') for p in
basedir[sys.platform] ]+
[os.path.join(p, 'lib64') for p in
basedir[sys.platform] ] )
module.include_dirs.extend(incdirs)
module.include_dirs.append('.')
module.library_dirs.extend(libdirs)
-------------------------------------
(and we leave the definition of basedir alone). That puts the sage
directories in front of the platform-specific directories on all platforms.
Thanks,
Jason
Dr. David Kirkby
> On 6/10/10 6:01 AM, Dr. David Kirkby wrote:
>> Thank you. Having read src/docs/VERSION.DLL, I see that there are in
>> fact *three* different numbers all associated with the version. It is
>> any wonder I've been confused?
>>
>
> Now *I'm* confused :).
I can't possibly understand why!
> What is the conclusion?
matplotlib is *not* finding the correct (i.e Sage supplied) version of freetype
on Solaris, and I doubt it is on linux either, though I may be wrong about Linux.
> Does anything need to be
> done?
Yes, it does, but exactly what I do not know. Go ahead and update matplotlib,
that can't do any harm.
Certainly on Solaris 10, the version of freetype2 being reported by matplotlib
is the one in /usr/sfw, and not the one in Sage.
drkirkby@redstart:~$ /usr/bin/pkg-config --modversion --cflags --libs freetype2
9.7.3
indicates version 9.7.3, which is also known as 2.1.9 and has a library version
of 6.3.7 . (See table I posted). That is different to the version of freetype in
Sage, which is 2.3.5 (aka 9.17.3)
On sage.math, I expect that is broken too, but I'm not 100% sure, as the version
of freetype installed globally on sage.math is 9.16.2 (aka 2.3.5), which is
conincidently the same version supplied in the Sage tarball. Hence it's not
possible to tell where matplotlib has found freetype from on sage.math (or
boxen.math), since they both version as in Sage.
I assume you have a linux box there. Can you check the output of
/usr/bin/pkg-config --modversion freetype2
Hopefully it will show something other than 9.17.3. If it does, then it would be
useful to compare that version with whatever matplotlib says is your freetype2
version (just grep for "freetype2:" in install.log).
The only two systems I have access to (boxen.math and sage.math) happen to have
version 9.16.2 (aka 2.3.5), which is the same version as in Sage. So I can't
easily tell where matplotlib is finding freetype2 from.
> I'm in the process of updating matplotlib in Sage to 0.99.3 to get a
> needed bugfix into the Sage version. David: are you working on the spkg
> too?
Yes. Can you create a ticket, and cc me on it. Should I find the fix before you
do, then I'll let you know. If not, just release a new matplotlib. I've tried
the latest version of matplotlib, but it does not fix the issues I have on
Solaris. I'm just in the process of building Sage on 'sage.math' and will try a
new freetype on there, and see what happens.
> Thanks,
> Jason Grout
Dave
Dr. David Kirkby
Note also
1) There is a section "def check_for_freetype():"
2) The code seems to have changed in the latest matplotlib, so I would not waste
too much time over that in Sage if you intend updating matplotlib. I'd fix it
after updating.
Dave
Jason Grout
>> I'm in the process of updating matplotlib in Sage to 0.99.3 to get a
>> needed bugfix into the Sage version. David: are you working on the spkg
>> too?
>
> Yes. Can you create a ticket, and cc me on it. Should I find the fix
> before you do, then I'll let you know. If not, just release a new
> matplotlib. I've tried the latest version of matplotlib, but it does not
> fix the issues I have on Solaris. I'm just in the process of building
> Sage on 'sage.math' and will try a new freetype on there, and see what
> happens.
I've posted the update to http://trac.sagemath.org/sage_trac/ticket/9202
Actually, I'm pretty sure I fixed the issue in this thread with the new
spkg (see my other message in this thread for a discussion of what the
issue is, or see the hg commit log in the new spkg). I also removed
another solaris-specific patch that we apply, that I'm pretty sure is
obsolete as of a year ago or so.
Can you check the new spkg on Solaris and let us know if there are any
problems?
Thanks,
Jason
Jason Grout
>
> Note also
> 1) There is a section "def check_for_freetype():"
Yes, good point. My hope is that *prepending* the sage directories will
have taken care of the problem, as check_for_freetype works with that
list of directories.
> 2) The code seems to have changed in the latest matplotlib, so I would
> not waste too much time over that in Sage if you intend updating
> matplotlib. I'd fix it after updating.
>
I have to update the patches anyway for the upgrade (because setupext.py
had changed), so I had to look at this anyway.
Thanks,
Jason
Dr. David Kirkby
No, it has not fixed it. Leaving pkg-config working, matplotlib reports version
REQUIRED DEPENDENCIES
numpy: 1.3.0
freetype2: 9.7.3
That's the version in /usr/sfw. When I change the permission of the files in
/usr/sfw so they can't be read, I get an error while installing matplotlib.
/export/home/drkirkby/32/sage-4.4.3/local/lib/python2.6/site-packages/numpy/core/include/numpy/npy_interrupt.h:83:20:
error: /usr/sfw/include/freetype2/setjmp.h: Permission denied
So we can see, matplotlib is still trying to read from /usr/sfw.
From what I've been playing around with, the only way I can get matplotlib to
find the sage version is to stop pkg-config from working.
drkirkby@redstart:~/32/sage-4.4.3/spkg/standard$ su
Password:
# chmod 000 /usr/bin/pkg-config
# exit
Then, it would appear that matplotlib finds the freetype2 version in Sage,
though it is unable to find the version number.
REQUIRED DEPENDENCIES
numpy: 1.3.0
freetype2: found, but unknown version (no pkg-config)
I think the solution will revolve around stopping matplotlib making use of the
output from the pkg-config command. If you can do that, it should find the
version in Sage, and will report "freetype2: found, but unknown version (no
pkg-config)"
It seems at the minute, that pkg-config is used in preference to any settings
that we have so far tried.
Dave
Willem Jan Palenstijn
> On 06/10/10 01:19 PM, Jason Grout wrote:
>> I've posted the update to http://trac.sagemath.org/sage_trac/ticket/9202
>>
>> Actually, I'm pretty sure I fixed the issue in this thread with the new
>> spkg (see my other message in this thread for a discussion of what the
>> issue is, or see the hg commit log in the new spkg). I also removed
>> another solaris-specific patch that we apply, that I'm pretty sure is
>> obsolete as of a year ago or so.
>>
>> Can you check the new spkg on Solaris and let us know if there are any
>> problems?
>>
>> Thanks,
>>
>> Jason
>
> No, it has not fixed it. Leaving pkg-config working, matplotlib reports version
>
> REQUIRED DEPENDENCIES
> numpy: 1.3.0
> freetype2: 9.7.3
Are you really sure that using PKG_CONFIG_PATH doesn't fix that?
i.e., if you have the file /export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig/freetype2.pc, then
$ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig
$ pkg-config --modversion freetype2
should really return 9.16.3. If it doesn't, I think we should try to figure out
why not, rather than add hack upon hack...
In general I think it would make a lot of sense to set PKG_CONFIG_PATH in
sage-env. In any case we could set it in the matplotlib spkg-install if that
helps.
-Willem Jan
Dr. David Kirkby
> On Thu, Jun 10, 2010 at 01:32:19PM +0100, Dr. David Kirkby wrote:
>> On 06/10/10 01:19 PM, Jason Grout wrote:
>>> I've posted the update to http://trac.sagemath.org/sage_trac/ticket/9202
>>>
>>> Actually, I'm pretty sure I fixed the issue in this thread with the new
>>> spkg (see my other message in this thread for a discussion of what the
>>> issue is, or see the hg commit log in the new spkg). I also removed
>>> another solaris-specific patch that we apply, that I'm pretty sure is
>>> obsolete as of a year ago or so.
>>>
>>> Can you check the new spkg on Solaris and let us know if there are any
>>> problems?
>>>
>>> Thanks,
>>>
>>> Jason
>>
>> No, it has not fixed it. Leaving pkg-config working, matplotlib reports version
>>
>> REQUIRED DEPENDENCIES
>> numpy: 1.3.0
>> freetype2: 9.7.3
>
>
> Are you really sure that using PKG_CONFIG_PATH doesn't fix that?
>
> i.e., if you have the file /export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig/freetype2.pc, then
>
> $ export PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig
> $ pkg-config --modversion freetype2
Yes, sorry, that is working. Not sure what I typed before, but that does work.
rkirkby@redstart:~$ grep Version
/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig/freetype2.pc
Version: 9.16.3
drkirkby@redstart:~$ export
PKG_CONFIG_PATH=/export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig
drkirkby@redstart:~$ pkg-config --modversion freetype2
9.16.3
drkirkby@redstart:~$
I could have swore I set that before! I apologise for the confusion.
$ ./sage -f matplotlib-0.99.3 | grep freetype2:
freetype2: 9.16.3
> should really return 9.16.3. If it doesn't, I think we should try to figure out
> why not, rather than add hack upon hack...
Sorry about that.
> In general I think it would make a lot of sense to set PKG_CONFIG_PATH in
> sage-env. In any case we could set it in the matplotlib spkg-install if that
> helps.
It sounds to me that we should set it in sage-env, since there are several
packages which get built in Sage whose .pc files reside in
$SAGE_LOCAL/lib/pkgconfig.
drkirkby@redstart:~/32/sage-4.4.3$ ls local/lib/pkgconfig
bdw-gc.pc gnutls.pc libpng12.pc pynac.pc
freetype2.pc gsl.pc libR.pc sqlite3.pc
gnutls-extra.pc libpng.pc opencdk.pc
This could mean several packages are picking up the wrong versions of software,
if they make use of pkgconfig
Note however pkgconfig does not appear to be on OS X (or at least in the version
of OS X on bsd.math).
[kirkby@bsd ~]$ uname -a
Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST
2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1 Darwin
[kirkby@bsd ~]$ pkgconfig
-bash: pkgconfig: command not found
though pkg-config exists on both Solaris (even my March 2005 release) and Linux
systems.
So what will happen on Linux?
>
> -Willem Jan
>
Thank you for your help Willem
Dave
Dr. David Kirkby
> Note however pkgconfig does not appear to be on OS X (or at least in the
> version of OS X on bsd.math).
>
>
> [kirkby@bsd ~]$ uname -a
> Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26
> 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1
> Darwin
> [kirkby@bsd ~]$ pkgconfig
> -bash: pkgconfig: command not found
>
> though pkg-config exists on both Solaris (even my March 2005 release)
> and Linux systems.
>
> So what will happen on Linux?
I mean what will happen on OS X?
It seems there may need to be another way on OS X at least to determine how to
link freetype and possibly all the other ten packages which create .pc files and
put them in /export/home/drkirkby/32/sage-4.4.3/local/lib/pkgconfig
Setting PKG_CONFIG_PATH may not be sufficient on OS X.
Dave
leif
On 10 Jun., 20:04, "Dr. David Kirkby" <david.kir...@onetel.net> wrote:
> Note however pkgconfig does not appear to be on OS X (or at least in the version
> of OS X on bsd.math).
>
> [kirkby@bsd ~]$ uname -a
> Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST
> 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1 Darwin
> [kirkby@bsd ~]$ pkgconfig
> -bash: pkgconfig: command not found
>
> though pkg-config exists on both Solaris (even my March 2005 release) and Linux
> systems.
-Leif
Dr. David Kirkby
Above was a typo, but it does not change the fact OS X lacks this
[kirkby@bsd ~]$ pkg-config
-bash: pkg-config: command not found
or if it does exist, it is not in my path, and not at the most obvious place
[kirkby@bsd ~]$ /usr/bin/pkg-config
-bash: /usr/bin/pkg-config: No such file or directory
Jason Grout
> On 06/10/10 07:04 PM, Dr. David Kirkby wrote:
>
>> Note however pkgconfig does not appear to be on OS X (or at least in the
>> version of OS X on bsd.math).
>>
>>
>> [kirkby@bsd ~]$ uname -a
>> Darwin bsd.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26
>> 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 i386 MacPro1,1
>> Darwin
>> [kirkby@bsd ~]$ pkgconfig
>> -bash: pkgconfig: command not found
>>
>> though pkg-config exists on both Solaris (even my March 2005 release)
>> and Linux systems.
>>
>> So what will happen on Linux?
>
> I mean what will happen on OS X?
>
I have pkg-config installed automatically via MacPorts, so at least some
OSX systems will have the program. In the case of matplotlib, it looks
like it has a fallback (which is taken care of in the patches in the
update spkg)
Thanks,
Jason
Georg S. Weber
> > I mean what will happen on OS X?
>
> I have pkg-config installed automatically via MacPorts, so at least some
> OSX systems will have the program. In the case of matplotlib, it looks
> like it has a fallback (which is taken care of in the patches in the
> update spkg)
>
> Thanks,
>
> Jason
move MacPorts/Fink "out of the way", e.g. by renaming the paths (/
opt/... and /sw/...), and for good reason --- there have been too many
problems in the past. So relying on a program from there is not a way
to go at the time being.
The two "opposite" solutions are either to make sure that no spkg uses
"pkg-config" (they all should have fallback scenarios, which one could
make the default), or else include a version of pkg-config in Sage as
a spkg of its own (this would add less than 1 MB to the Sage tarball.
looking at the latest tarball "pkg-config-0.24.tar.gz"), and make sure
that other spkgs relying on that do use this pkg-config binary
provided by the Sage distribution. I don't think any solution "in
between" could be satisfactory in the end.
(IMHO, the Sage build system would only profit from having pkg-config
as one "battery included", and relying on its facilities for its own
purposes --- e.g. having a distinction between a "src package" like
the "original" matplotlib and packages like "matplotlib-spkg" where
Sage notes in the corresponding ".pc" file its very own dependencies
on other SagePackages. But I simply don't find the time to even make
plans in that direction.)
Cheers,
Georg
David Kirkby
That's an interesting idea, though worth noting is
FOR
1) About 11 packages in Sage write .pc files for use by pkg-config.
All these .pc files exist in Sage
bdw-gc.pc gnutls.pc libpng12.pc pynac.pc
freetype2.pc gsl.pc libR.pc sqlite3.pc
gnutls-extra.pc libpng.pc opencdk.pc
2) At the bare minimum matplotlib makes use of the output from
pkg-config, but I suspect others do too.
3) I can't think of a very good workaround, other than we go around
hacking matplot lib and any other packages which assume pkg-config
exists.
AGAINST
1) It adds even more bloat.
2) If a system has pkg-config installed, it will have the location of
various system packages. That information will be unavailable to Sage,
so some extras like GTK, which would be linked with matplotlib if they
existed, will not be found.
As such, if pkg-config was added, I think it should only be used on
platforms which do not already have it.
#!/bin/sh
if [ `command -v pkg-config` ] ; then
echo "No need to build pkg-config - your system has it"
exit 0
fi
Note, under no circumstances use 'which' to test if a command exits or not.
'which' is not defined by POSIX and on whilst it exists on Solaris 10,
the return code is undefined.
In contrast, 'command -v' is defined by POSIX, prints the path like
'which' so is a drop in portable replacement.
It wont take too long to create such a package and updated 'deps' to
add its dependences if that is what is needed, but I know adding
standard packages is not without risks.
Dave
Jason Grout
>>
>>> I mean what will happen on OS X?
>>
>> I have pkg-config installed automatically via MacPorts, so at least some
>> OSX systems will have the program. In the case of matplotlib, it looks
>> like it has a fallback (which is taken care of in the patches in the
>> update spkg)
>>
>> Thanks,
>>
>> Jason
>
> If one wants to build Sage under Mac OS, currently it is advised to
> move MacPorts/Fink "out of the way", e.g. by renaming the paths (/
> opt/... and /sw/...), and for good reason --- there have been too many
> problems in the past. So relying on a program from there is not a way
> to go at the time being.
In my case, the problem was that the macports pkg-config was picking up
the system (i.e., macports) version of freetype2, since we weren't
setting the PKG_CONFIG_PATH variable. Once we set that to point to the
local Sage pkg-config directory (SAGE_ROOT/local/lib/pkgconfig),
matplotlib used pkg-config to correctly pick up the local Sage
installation of freetype. So I wonder if that is the root of our
macports problems! If so, then #9208 is a good fix.
In my case, I usually build Sage and then move the directory. This
invalidates the paths in the Sage pkgconfig files. So #9210 fixes that
by originally rewriting the SAGE_ROOT paths in pkgconfig to use a
SAGE_ROOT variable, and then every time Sage is moved, the SAGE_ROOT
variable is updated. That seems to work for me (famous last words, I
know!). The patch is up at #9210 and ready for review (David has been
working on reviewing it, for example).
Jason Grout
Or we can just modify the .pc files like in #9210.
>
> AGAINST
> 1) It adds even more bloat.
> 2) If a system has pkg-config installed, it will have the location of
> various system packages. That information will be unavailable to Sage,
> so some extras like GTK, which would be linked with matplotlib if they
> existed, will not be found.
>
+1. Using our own pkg-config is asking for maintaining an entire
distribution. While we have included standard packages on occasion, I'd
love to see us move to using system packages when possible.
Dr. David Kirkby
But, if my understanding is correct, pkg-config uses the .pc files, and programs
are supposed to call pkg-config. In which case, there is no point hacking .pc
files if we don't have pkg-config.
>> AGAINST
>> 1) It adds even more bloat.
>> 2) If a system has pkg-config installed, it will have the location of
>> various system packages. That information will be unavailable to Sage,
>> so some extras like GTK, which would be linked with matplotlib if they
>> existed, will not be found.
>>
>
> +1. Using our own pkg-config is asking for maintaining an entire
> distribution. While we have included standard packages on occasion, I'd
> love to see us move to using system packages when possible.
Yes, me too.
Dave