Bug 280 - Cross-compile build fails
Summary: Cross-compile build fails
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.2
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: J. Ali Harlow
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-06 16:02 UTC by J. Ali Harlow
Modified: 2005-02-08 04:08 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Proposed fix (5.20 KB, patch)
2004-03-06 16:03 UTC, J. Ali Harlow
Details | Splinter Review
Updated patch (6.16 KB, patch)
2005-01-05 11:38 UTC, J. Ali Harlow
Details | Splinter Review

Description J. Ali Harlow 2004-03-06 16:02:19 UTC
fontconfig fails to build under a cross-compile environment because it compiles
tools to use during the build process, but takes no measures to deal with the
host/build issues that this raises.

I've put together a patch to allow fontconfig to build under a cross-compile 
environment. Tested with linux-x-mingw and native linux.

Disclaimers:

* I'm an autoconf newbie, so I could have made a complete pig's ear.
* The patch really ought to be tested under native mingw.
* I haven't tested it beyond seeing that it builds.
* fc-lang and fc-glyphname are built without any special attention to freetype 
cflags. This means that they will end up including headers from the host 
version of freetype rather than the build version. This may not be a problem; 
it may even be an advantage, but I haven't taken any account of it.
* I have assumed that the output of fc-cache is shareable (portable).
Comment 1 J. Ali Harlow 2004-03-06 16:03:11 UTC
Created attachment 129 [details] [review]
Proposed fix
Comment 2 Keith Packard 2004-12-04 21:42:10 UTC
The patch doesn't work with my version of the autotools (automake 1.79, autoconf
2.59) which complains bitterly about multiple definitions of CC and EXEEXT in
each directory.  Here's a sample from fc-glyphname.

fc-glyphname/Makefile.am:28: ... `LINK' previously defined here.
fc-lang/Makefile.am: unterminated conditionals: CROSS_COMPILING_TRUE
fc-lang/Makefile.am:26: CC was already defined in condition TRUE, which implies
condition CROSS_COMPILING_TRUE ...
configure.in:57: ... `CC' previously defined here.

Also, I don't want to assume that fontconfig is already installed; I suggest
that in a cross compiling environment, fc-cache needn't be run at all; we can
assume that however the package gets installed in the target system will fix any
font cache issues.

I'd love to have this functionality in fontconfig, but I don't have any way to
test whether cross compiling works, especially to or from DOS.
Comment 3 J. Ali Harlow 2005-01-05 11:38:33 UTC
Created attachment 1637 [details] [review]
Updated patch

I can't explain the problems you're reporting with my patch. It works for me
quite happily with autoconf 2.59 and automake 1.7.9

In any event, I've updated the patch for 2.2.98 (tested against CVS of
2005-01-04) . As requested it no longer uses a native build of fc-cache and
doesn't create fonts.cache when cross-compiling.
Comment 4 Keith Packard 2005-01-13 10:21:34 UTC
Thanks for the patch; it works for me.
Comment 5 Tommy 2005-02-08 16:26:16 UTC
(In reply to comment #3)
Hi Ali,

Does the patch work for fontconfig 2.2.3?  I seem to have error running it. 
Would this patch be incorporated into a future version so that we don't have to
patch it?

Tommy

> Created an attachment (id=1637) [edit]
> Updated patch
> 
> I can't explain the problems you're reporting with my patch. It works for me
> quite happily with autoconf 2.59 and automake 1.7.9
> 
> In any event, I've updated the patch for 2.2.98 (tested against CVS of
> 2005-01-04) . As requested it no longer uses a native build of fc-cache and
> doesn't create fonts.cache when cross-compiling.

Comment 6 J. Ali Harlow 2005-02-08 23:08:10 UTC
I don't know if the patch would work against 2.2.3 - I suspect not. The patch is
incorporated into version 2.2.99 see
http://lists.freedesktop.org/archives/fontconfig/2005-January/001136.html


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.