Bug 455

Summary:	Fontconfig problem problem when building/installing
Product:	buildroot	Reporter:	Lionel Landwerlin <llandwerlin>
Component:	Other	Assignee:	unassigned
Status:	RESOLVED INVALID
Severity:	enhancement	CC:	buildroot
Priority:	P5
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Host:	x86-64	Target:	SH4
Build:
Attachments:	Fontconfig fix for build/install External toolchain path order fix

Description Lionel Landwerlin 2009-07-13 19:08:44 UTC

Hi,

when building/installing fontconfig, you might find a problem with make trying to call $(STAGING_DIR)/bin/sh. Of course it won't work.

Please find a fix as attachment.

Regards,

Lionel

Comment 1 Lionel Landwerlin 2009-07-13 19:09:21 UTC

Created attachment 461 [details]
Fontconfig fix for build/install

Comment 2 Peter Korsgaard 2009-07-13 20:20:29 UTC

Hmm, please make the patch as minimal as possible - E.G. the fix-makealias patch has a bunch of noise because it removes trailing spaces.

I don't get what the problem is as the Makefile calls sh and not $PREFIX/bin/sh - Is it because you have a sh for the target in $STAGING_DIR/bin and that included in the path?

Comment 3 Lionel Landwerlin 2009-07-13 21:48:52 UTC

(In reply to comment #2)
> Hmm, please make the patch as minimal as possible - E.G. the fix-makealias
> patch has a bunch of noise because it removes trailing spaces.
> 
> I don't get what the problem is as the Makefile calls sh and not $PREFIX/bin/sh
> - Is it because you have a sh for the target in $STAGING_DIR/bin and that
> included in the path?
> 

Yes, I have an $(STAGING_DIR)/bin/sh installed.

Comment 4 Lionel Landwerlin 2009-07-13 21:57:24 UTC

I have another patch that also fixed the problem of glib-genmarshall called from the staging directory.

Comment 5 Lionel Landwerlin 2009-07-13 21:58:28 UTC

Created attachment 465 [details]
External toolchain path order fix

Comment 6 Peter Korsgaard 2009-07-14 10:21:43 UTC

> Yes, I have an $(STAGING_DIR)/bin/sh installed.

Ohh? Where does that come from - Bash? That sounds like a bug in the first place

Comment 7 Lionel Landwerlin 2009-07-14 13:03:32 UTC

(In reply to comment #6)
> > Yes, I have an $(STAGING_DIR)/bin/sh installed.
> 
> Ohh? Where does that come from - Bash? That sounds like a bug in the first
> place
> 

That's copied from the external toolchain.
Whatever is in the staging we shouldn't have that kind of problem.

Comment 8 Lionel Landwerlin 2009-07-14 13:57:30 UTC

(In reply to comment #7)
> (In reply to comment #6)
> > > Yes, I have an $(STAGING_DIR)/bin/sh installed.
> > 
> > Ohh? Where does that come from - Bash? That sounds like a bug in the first
> > place
> > 
> 
> That's copied from the external toolchain.
> Whatever is in the staging we shouldn't have that kind of problem.
> 

I think we should remove the staging directory from the PATH variable, as none of the binaries it contains can be executed on the host. If some package need to execute one binary from another package, we should have this compiled for the host.

Comment 9 Lionel Landwerlin 2009-07-14 20:03:11 UTC

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > > Yes, I have an $(STAGING_DIR)/bin/sh installed.
> > > 
> > > Ohh? Where does that come from - Bash? That sounds like a bug in the first
> > > place
> > > 
> > 
> > That's copied from the external toolchain.
> > Whatever is in the staging we shouldn't have that kind of problem.
> > 
> 
> I think we should remove the staging directory from the PATH variable, as none
> of the binaries it contains can be executed on the host. If some package need
> to execute one binary from another package, we should have this compiled for
> the host.
> 

I confirm that removing the staging dir from the PATH variable also fix the problem. I going to close the bug as there is no problem related to fontconfig but rather to the external toolchain usage.

Thx for helping.

Comment 10 Peter Korsgaard 2009-07-14 20:21:52 UTC

> I think we should remove the staging directory from the PATH variable, as none
> of the binaries it contains can be executed on the host. If some package need
> to execute one binary from another package, we should have this compiled for
> the host.

The problem is the various *-config scripts, like sdl-config which get installed by various packages and *SHOULD* get called instead of whatever is present on the host.

Comment 11 Lionel Landwerlin 2009-07-14 20:38:18 UTC

(In reply to comment #10)
> > I think we should remove the staging directory from the PATH variable, as none
> > of the binaries it contains can be executed on the host. If some package need
> > to execute one binary from another package, we should have this compiled for
> > the host.
> 
> The problem is the various *-config scripts, like sdl-config which get
> installed by various packages and *SHOULD* get called instead of whatever is
> present on the host.
> 

I'm agree, but shouldn't we provides them from the $(HOST_DIR) ?

Comment 12 Peter Korsgaard 2009-07-15 07:31:07 UTC

(In reply to comment #11)

> > The problem is the various *-config scripts, like sdl-config which get
> > installed by various packages and *SHOULD* get called instead of whatever is
> > present on the host.
> 
> I'm agree, but shouldn't we provides them from the $(HOST_DIR) ?

Well, it's not that simple. HOST_DIR is for stuff for the host, so a sdl-config there would point to the host libraries, not the target ones. Also notice that these scripts gets installed with make install of the packages, so we don't have direct control over it. And finally don't forget the cross compiler which also gets installed into STAGING_DIR together with the headers/libs, and people expect to simply be able to add STAGING_DIR/usr/bin to their path and be good to go.