#9864: Error building PIL on RHEL Server 5.5
--------------------------------------------+-------------------------------
Reporter: mpatel | Owner: GeorgSWeber
Type: defect | Status: needs_work
Priority: blocker | Milestone: sage-4.6.1
Component: build | Keywords:
Author: Leif Leonhardy, Mitesh Patel | Upstream: N/A
Reviewer: | Merged:
Work_issues: make patches #9419-compliant |
--------------------------------------------+-------------------------------
Comment(by drkirkby):
Replying to [comment:35 leif]:
> Replying to [comment:34 Koen]:
> > I'm having issues with PIL 1.1.6p2 (the release version) not finding
its JPEG libraries. These are located in /usr/lib64 on CentOS 5.5 /
OpenSuse, however the default library path only considers /usr/lib. Adding
/usr/lib64 as a library path fixes the problem in my stand-alone PIL
build. I'm not quite sure how to patch the setup.py in SAGE to add this
path by default.
>
> Well, we should just check if `/usr/lib64` (and `/usr/local/lib64`)
exist, and if so, add these '''instead of''' `/usr/lib` etc., unless
`realpath("/usr/lib64") == realpath("/usr/lib")`. (We may also check we're
really on a 64-bit system, too, though the presence of `/usr/lib64` should
normally indicate that.
> I'm having issues with PIL 1.1.6p2 (the release version) not finding its
JPEG libraries. These are located in /usr/lib64 on CentOS 5.5 / !OpenSuse,
however the default library path only considers /usr/lib. Adding
/usr/lib64 as a library path fixes the problem in my stand-alone PIL
build. I'm not quite sure how to patch the setup.py in SAGE to add this
path by default.
Is it essential to have the JPEG libraries? If not, then they should be
excluded when {{{SAGE_FAT_BINARY=yes}}}, otherwise we risk breakages if
people install a Sage binary on a system without these libraries.
I'm puzzled why it should be necessary to so add {{{/usr/lib64}}}. Has
someone mis-configured the system?
On every system that I know, that is able to build both 32-bit and 64-bit
libraries, the runtime lnker will always search for the 64-bit ones when
building 64-bit code. On Solaris the 64-bit libraries are in
{{{/usr/lib/sparcv9}}} or {{{/usr/lib/amd64}}}, depending on the CPU type.
But the run time linker knows that, and will search for them:One never
needs to put {{{/usr/lib/sparcv9}}} or {{{/usr/lib/amd64}}} in any sort of
PATH (LD_LIBRARY_PATH etc).
{{{
-bash-3.00$ crle
Default configuration file (/var/ld/ld.config) not found
Default Library Path (ELF): /lib:/usr/lib (system default)
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system
default)
-bash-3.00$ crle -64
Default configuration file (/var/ld/64/ld.config) not found
Default Library Path (ELF): /lib/64:/usr/lib/64 (system default)
Trusted Directories (ELF): /lib/secure/64:/usr/lib/secure/64 (system
default)
-bash-3.00$
}}}
It's a complely different matter in directories like
{{{/usr/local/lib/sparcv9}}} since the run time linker does not to search
there.
I know this is true on HP-UX too.
On AIX, the libraries are in an archives containing both 32-bit and 64-bit
libraries in the same archive. But again, the run-time linker knows how to
find them.
Clearly if the system is mis-configured, we should not work around the
problem.
I think we should ascertain if someone has mis-configured the system
before proceeding to patch Sage
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9864#comment:37>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
