What's up with "fontconfig"

What's up with "fontconfig"

[Mike Looijmans]

When compiling fontconfig, it fails because it is using "build" flags in 
the host compiler. I have BUILD_OPTIMIZATIONS="-march=native ..." set, 
and fontconfig will fail to compile because it passes the -march=native 
flag to the ARM compiler which then fails. Which is justified.

This is the part in the recipe that worries me:

do_configure_append () {
	sed -i 's|LDFLAGS =.*|LDFLAGS =|' fc-case/Makefile
	sed -i 's|LDFLAGS =.*|LDFLAGS =|' fc-glyphname/Makefile
	sed -i 's|LDFLAGS =.*|LDFLAGS =|' fc-lang/Makefile

	sed -i 's|CFLAGS =.*|CFLAGS =${BUILD_CFLAGS}|' fc-case/Makefile
	sed -i 's|CFLAGS =.*|CFLAGS =${BUILD_CFLAGS}|' fc-glyphname/Makefile
	sed -i 's|CFLAGS =.*|CFLAGS =${BUILD_CFLAGS}|' fc-lang/Makefile

	sed -i 's|CPPFLAGS =.*|CPPFLAGS =${BUILD_CPPFLAGS}|' fc-case/Makefile
	sed -i 's|CPPFLAGS =.*|CPPFLAGS =${BUILD_CPPFLAGS}|' fc-glyphname/Makefile
	sed -i 's|CPPFLAGS =.*|CPPFLAGS =${BUILD_CPPFLAGS}|' fc-lang/Makefile

	sed -i 's|CXXFLAGS =.*|CFLAGS =${BUILD_CXXFLAGS}|' fc-case/Makefile
	sed -i 's|CXXFLAGS =.*|CFLAGS =${BUILD_CXXFLAGS}|' fc-glyphname/Makefile
	sed -i 's|CXXFLAGS =.*|CFLAGS =${BUILD_CXXFLAGS}|' fc-lang/Makefile

}

This is not a "native" package. The above commands put the build systems 
include patch and compiler flags into the makefile.

I've worked around the issue by creating a a bbappend that simply 
removes "-march=native" from the build flags, which makes the build of 
this package succeed.

I have no idea what fontconfig is supposed to do and where it is 
supposed to run, but it looks to me as if that configure_append should 
not be there at all.


-- 
Mike Looijmans - TOPIC Automation

Re: What's up with "fontconfig"

[Burton, Ross]

On 1 February 2013 14:56, Mike Looijmans <mike.looijmans@topic.nl> wrote:
> I have no idea what fontconfig is supposed to do and where it is supposed to
> run, but it looks to me as if that configure_append should not be there at
> all.

Erm, yeah.  The git log that file stops in 2007 and they were present
then too, so the appearance of them isn't easy.

Fontconfig is good old autotools, so I expect we can remove the
--with-arch argument too.

And the method of appending to do_unpack is unconventional to say the least.

This recipe needs a good spring clean!

Ross

Re: What's up with "fontconfig"

[Burton, Ross]

On 1 February 2013 15:09, Burton, Ross <ross.burton@intel.com> wrote:
> Erm, yeah.  The git log that file stops in 2007 and they were present
> then too, so the appearance of them isn't easy.

Richard pointed out I didn't read the diff properly and it was me who
introduced this.

I have no idea what I was doing.

Ross

Re: What's up with "fontconfig"

[Richard Purdie]

On Fri, 2013-02-01 at 15:56 +0100, Mike Looijmans wrote:
> When compiling fontconfig, it fails because it is using "build" flags in 
> the host compiler. I have BUILD_OPTIMIZATIONS="-march=native ..." set, 
> and fontconfig will fail to compile because it passes the -march=native 
> flag to the ARM compiler which then fails. Which is justified.
> 
> This is the part in the recipe that worries me:
> 
> do_configure_append () {
> 	sed -i 's|LDFLAGS =.*|LDFLAGS =|' fc-case/Makefile
> 	sed -i 's|LDFLAGS =.*|LDFLAGS =|' fc-glyphname/Makefile
> 	sed -i 's|LDFLAGS =.*|LDFLAGS =|' fc-lang/Makefile
> 
> 	sed -i 's|CFLAGS =.*|CFLAGS =${BUILD_CFLAGS}|' fc-case/Makefile
> 	sed -i 's|CFLAGS =.*|CFLAGS =${BUILD_CFLAGS}|' fc-glyphname/Makefile
> 	sed -i 's|CFLAGS =.*|CFLAGS =${BUILD_CFLAGS}|' fc-lang/Makefile
> 
> 	sed -i 's|CPPFLAGS =.*|CPPFLAGS =${BUILD_CPPFLAGS}|' fc-case/Makefile
> 	sed -i 's|CPPFLAGS =.*|CPPFLAGS =${BUILD_CPPFLAGS}|' fc-glyphname/Makefile
> 	sed -i 's|CPPFLAGS =.*|CPPFLAGS =${BUILD_CPPFLAGS}|' fc-lang/Makefile
> 
> 	sed -i 's|CXXFLAGS =.*|CFLAGS =${BUILD_CXXFLAGS}|' fc-case/Makefile
> 	sed -i 's|CXXFLAGS =.*|CFLAGS =${BUILD_CXXFLAGS}|' fc-glyphname/Makefile
> 	sed -i 's|CXXFLAGS =.*|CFLAGS =${BUILD_CXXFLAGS}|' fc-lang/Makefile
> 
> }
> 
> This is not a "native" package. The above commands put the build systems 
> include patch and compiler flags into the makefile.
> 
> I've worked around the issue by creating a a bbappend that simply 
> removes "-march=native" from the build flags, which makes the build of 
> this package succeed.
> 
> I have no idea what fontconfig is supposed to do and where it is 
> supposed to run, but it looks to me as if that configure_append should 
> not be there at all.

This does look rather worrying and Ross mentioned this to me but wasn't
able to find the history. I was more successful and ironically this was
introduced by Ross:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c2d22f0f36980eecc7cf2ad818a5033476614bfc

We likely need to replace this with something sane. The question is
whether we need it at all and if so, what problem dies it solve?

Cheers,

Richard

Re: What's up with "fontconfig"

[Burton, Ross]

On 1 February 2013 15:21, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> We likely need to replace this with something sane. The question is
> whether we need it at all and if so, what problem dies it solve?

It looks a bit like an attempt to build native tools when compiling,
as FC_LANG and FC_GLYPHNAME are also overridden earlier in the file.
These variables don't appear to be used either.

For what it's worth, removing everything that looks dubious in
EXTRA_OECONF and that do_configure_append results in a zero-difference
buildhistory, so it at least compiles.  I'll kick off an image build
now and see if fonts still work.

Ross

Re: What's up with "fontconfig"

[Burton, Ross]

On 1 February 2013 17:22, Burton, Ross <ross.burton@intel.com> wrote:
> For what it's worth, removing everything that looks dubious in
> EXTRA_OECONF and that do_configure_append results in a zero-difference
> buildhistory, so it at least compiles.  I'll kick off an image build
> now and see if fonts still work.

I've pushed a branch to poky-contrib:ross/fontconfig that removes
everything that looks dubious.  I can't test it right now so anyone
else testing it builds for them and works as expected would be most
useful.

Ross