Re: [Fink-users] xetex build fails

[<Jea...@uc...>]

On 21 Sep 2007, at 18:44, LiKai Liu wrote:

> The reason NoSetCPPFLAGS and NoSetLDFLAGS are in xetex.info is because
> xetex is supposed to be self-contained. It supplies its own third- 
> party
> libraries in the libs/ directory.
If fink's policy is that pkgs should build shared libs if at all  
possible,
one can presume this is so that those be really shared _ ie, that
other pkgs should use them if at all possible, using at least all
available --with-system, etc
> Without the NoSet directives, xetex
> would end up using the Fink ones, which causes compile and link  
> problems.
I don't see this _ cf below
> That said, it's not supposed to have any external expat dependencies.
>
> I think the offender is somewhere in libs/teckit. It seems that SFconv
> uses expat,
right , the sfconv executable is the only one that takes symbols from  
libexpat
_ and is very happy with it, and is anyway not installed !
so there is no expat dep anyway ! just a builddep on expat1 (which is  
anyway
'almost' an essential pkg) to avoid eg Jens Noeckel's trouble..
> but it should be using its own copy.
Why ? Why re-create existing libs ?? And for something that's not  
even going to be installed !
> I'll need some time to
> take a look at this. By the way, can you send me a copy of the failed
> build output without SetLIBRARY_PATH setting?
>
> One of these days, I wish someone would write a tutorial on how to  
> cleanly
> isolate paths for those packages that prefer to use its own supplied
> third-party library.
cf above.  They shouldn't !
> Both for the package maintainer and for upstream
> Makefile authors.
____________
I think you didn't notice the difference between LDFLAGS and  
LIBRARY_PATH.
I can imagine that with %p/lib in the LDFLAGS, you might get some  
trouble, when
eg the flag comes before flags to the builddir..
But with LIBRARY_PATH that risk disappears.
So, to check on your claim, I did a build of unmodified xetex  (no  
install: I don't want
it to clobber all my configuration files! _and the attempted patch of  
them would more
than likely fail, since they ARE configured !)  _  and then rebuilt  
with the
following modifications:

# diff xetex.info xetex.info.new
62a63
 > SetLIBRARY_PATH: %p/lib/freetype219/lib:%p/lib
64a66,67
 > export PATH=%p/lib/freetype219/bin:${PATH}
 > export CPATH=%p/lib/freetype219/include:%p/lib/freetype219/include/ 
freetype2:%p/include
72c75
<       ../configure --prefix=%p --datadir=%p/share --with-system- 
zlib || exit
---
 >       ../configure --prefix=%p --datadir=%p/share --with-system- 
zlib --with-system-pnglib --with-system-freetype2 --with-system-icu||  
exit
85c88
<               LIBS="teckit icu-xetex freetype2"
---
 >               LIBS="teckit icu-xetex"

The CPATH stuff is just there as the brother of SetLIBRARY_PATH,
and the "with-system" come from:
"for f in `find . -name configure`; do echo $f; $f --help; done|fgrep  
with-system"
In order not to introduce a dep on x11, I decided to use freetype219  
as the
providing the --with-system-freetype2, hence the freetype additions  
to PATH,
CPATH and LIBRARY_PATH, and then clearly freetype2 had to be removed
from the LIBS line..

Result: builds w/o a glitch; the --with-system-pnglib seems w/o  
effect, but nothing
seems anyway to be built related to png; the  --with-system-icu seems  
also w/o
effect, but that is the case with many other pkgs, and probably  
results from
incompleteness of Apple's libicu (and/or of fink's libicu32-dev in  
failing to
supplement suficiently).
But the --with-system-freetype2 was effective; the only 'Mach-O' file  
in the whole
builddir that linked with it was xetex itself, but this one did take  
a dozen of
symbols from it, and this resulted in a size-reduction of 350K for the
installed xetex executable.

JF Mertens