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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fink-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-users
