[Buildroot] freetype: fix for multilib toolchain

[Buildroot] freetype: fix for multilib toolchain

[Matt Johnson]

FreeType's makefile needs to have the architecture (example, -march=armv4t) passed in the LDFLAGS in order to work properly with a multilib toolchain, like CodeSourcery.  This is the easiest way I could think of to do it.  Tested and works.
 
Signed-off-by: Matt Johnson <mj1856@hotmail.com>
---
 package/freetype/freetype.mk |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/package/freetype/freetype.mk b/package/freetype/freetype.mk
index ad4292f..7e59b57 100644
--- a/package/freetype/freetype.mk
+++ b/package/freetype/freetype.mk
@@ -8,6 +8,7 @@ FREETYPE_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/
 FREETYPE_SOURCE = freetype-$(FREETYPE_VERSION).tar.bz2
 FREETYPE_INSTALL_STAGING = YES
 FREETYPE_INSTALL_TARGET = YES
+FREETYPE_CONF_ENV = LDFLAGS="-march=$(CC_TARGET_ARCH_) $(TARGET_LDFLAGS)"
 FREETYPE_MAKE_OPT = CCexe="$(HOSTCC)"
 FREETYPE_DEPENDENCIES = host-pkg-config $(if $(BR2_PACKAGE_ZLIB),zlib)
 
-- 
1.7.1 		 	   		  

[Buildroot] freetype: fix for multilib toolchain

[Thomas Petazzoni]

Hello Matt,

On Thu, 13 Jan 2011 21:18:33 -0700
Matt Johnson <mj1856@hotmail.com> wrote:

> FreeType's makefile needs to have the architecture (example, -march=armv4t) passed in the LDFLAGS in order to work properly with a multilib toolchain, like CodeSourcery.  This is the easiest way I could think of to do it.  Tested and works.

The description of your patch should be wrapped at ~80 columns.

> Signed-off-by: Matt Johnson <mj1856@hotmail.com>
> ---
>  package/freetype/freetype.mk |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> diff --git a/package/freetype/freetype.mk b/package/freetype/freetype.mk
> index ad4292f..7e59b57 100644
> --- a/package/freetype/freetype.mk
> +++ b/package/freetype/freetype.mk
> @@ -8,6 +8,7 @@ FREETYPE_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/
>  FREETYPE_SOURCE = freetype-$(FREETYPE_VERSION).tar.bz2
>  FREETYPE_INSTALL_STAGING = YES
>  FREETYPE_INSTALL_TARGET = YES
> +FREETYPE_CONF_ENV = LDFLAGS="-march=$(CC_TARGET_ARCH_) $(TARGET_LDFLAGS)"

I am not sure I want to see this fixed this way. It looks like the
issue reported by Divick Kishore on sshd is similar: we need to pass
the -march argument in the LDFLAGS for all packages.

So probably we should rather adjust TARGET_LDFLAGS globally (its
definition is in package/Makefile.in) so that it contains the
appropriate -march.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] freetype: fix for multilib toolchain

[Bjørn Forsman]

Hi,

On 14 January 2011 09:11, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello Matt,
>
> On Thu, 13 Jan 2011 21:18:33 -0700
> Matt Johnson <mj1856@hotmail.com> wrote:
>
>> FreeType's makefile needs to have the architecture (example, -march=armv4t) passed in the LDFLAGS in order to work properly with a multilib toolchain, like CodeSourcery. ?This is the easiest way I could think of to do it. ?Tested and works.
>
> The description of your patch should be wrapped at ~80 columns.
>
>> Signed-off-by: Matt Johnson <mj1856@hotmail.com>
>> ---
>> ?package/freetype/freetype.mk | ? ?1 +
>> ?1 files changed, 1 insertions(+), 0 deletions(-)
>> diff --git a/package/freetype/freetype.mk b/package/freetype/freetype.mk
>> index ad4292f..7e59b57 100644
>> --- a/package/freetype/freetype.mk
>> +++ b/package/freetype/freetype.mk
>> @@ -8,6 +8,7 @@ FREETYPE_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/
>> ?FREETYPE_SOURCE = freetype-$(FREETYPE_VERSION).tar.bz2
>> ?FREETYPE_INSTALL_STAGING = YES
>> ?FREETYPE_INSTALL_TARGET = YES
>> +FREETYPE_CONF_ENV = LDFLAGS="-march=$(CC_TARGET_ARCH_) $(TARGET_LDFLAGS)"
>
> I am not sure I want to see this fixed this way. It looks like the
> issue reported by Divick Kishore on sshd is similar: we need to pass
> the -march argument in the LDFLAGS for all packages.
>
> So probably we should rather adjust TARGET_LDFLAGS globally (its
> definition is in package/Makefile.in) so that it contains the
> appropriate -march.

AFAIK, ld does not have an "-march" option (just looked at the man page).
So I'd say that it is the freetype (and sshd?) package that needs to be fixed
(and not BR) because they are using LDFLAGS wrong.

Best regards,
Bj?rn Forsman

[Buildroot] freetype: fix for multilib toolchain

[Michael S. Zick]

On Fri January 14 2011, Bj?rn Forsman wrote:
> Hi,
> 
> On 14 January 2011 09:11, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Hello Matt,
> >
> > On Thu, 13 Jan 2011 21:18:33 -0700
> > Matt Johnson <mj1856@hotmail.com> wrote:
> >
> >> FreeType's makefile needs to have the architecture (example, -march=armv4t) passed in the LDFLAGS in order to work properly with a multilib toolchain, like CodeSourcery. ?This is the easiest way I could think of to do it. ?Tested and works.
> >
> > The description of your patch should be wrapped at ~80 columns.
> >
> >> Signed-off-by: Matt Johnson <mj1856@hotmail.com>
> >> ---
> >> ?package/freetype/freetype.mk | ? ?1 +
> >> ?1 files changed, 1 insertions(+), 0 deletions(-)
> >> diff --git a/package/freetype/freetype.mk b/package/freetype/freetype.mk
> >> index ad4292f..7e59b57 100644
> >> --- a/package/freetype/freetype.mk
> >> +++ b/package/freetype/freetype.mk
> >> @@ -8,6 +8,7 @@ FREETYPE_SITE = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/
> >> ?FREETYPE_SOURCE = freetype-$(FREETYPE_VERSION).tar.bz2
> >> ?FREETYPE_INSTALL_STAGING = YES
> >> ?FREETYPE_INSTALL_TARGET = YES
> >> +FREETYPE_CONF_ENV = LDFLAGS="-march=$(CC_TARGET_ARCH_) $(TARGET_LDFLAGS)"
> >
> > I am not sure I want to see this fixed this way. It looks like the
> > issue reported by Divick Kishore on sshd is similar: we need to pass
> > the -march argument in the LDFLAGS for all packages.
> >
> > So probably we should rather adjust TARGET_LDFLAGS globally (its
> > definition is in package/Makefile.in) so that it contains the
> > appropriate -march.
> 
> AFAIK, ld does not have an "-march" option (just looked at the man page).
> So I'd say that it is the freetype (and sshd?) package that needs to be fixed
> (and not BR) because they are using LDFLAGS wrong.
> 

Hmm...
there may be another source of confusion at work here also -
not one that changes the conclusion (fix is outside of BR).

First assumption: you are calling the "executable --help" function
rather than relying on "man" grabbing the correct man page 
on a machine with multiple tool chains installed.

I am basing this post on what I see from the Code Sourcery tool chain
builds for MIPS (mips-sde-elf-ld --help and mips-linux-gnu-ld --help) -
These tool chains are multi-lib configured tool chains.

I see a: 
-A ARCH to set the architecture
and a:
-m EMULATION to set the emulation

So it is possible for some processing grabbing the LDFLAGS and
translating an entry of "-march=..." (perhaps in the sshd and freetype
makefile author's build system) (I.E: ld being accessed via "gcc" front-end).

Which might account for the post's report of changing that option
fixing an observed problem. A vendor tool chain may be doing that conversion.

Four of the Code Sourcery, re-distributable, versions (for MIPS) are mirrored
from pages linked at the index page here:
http://mirrors.minimodding.com/index.html#menu-c
In case anyone needs to poke at possible vendor provided option processing.

Mike


> Best regards,
> Bj?rn Forsman
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] freetype: fix for multilib toolchain

[Thomas Petazzoni]

On Fri, 14 Jan 2011 07:31:28 -0600
"Michael S. Zick" <minimod@morethan.org> wrote:

> I see a: 
> -A ARCH to set the architecture

This option is architecture-specific:

      -A architecture
       --architecture=architecture
           In the current release of ld, this option is useful only for
      the Intel 960 family of architectures.  In that ld configuration,
      the architecture argument identifies the particular architecture
      in the 960 family, enabling some safeguards and modifying the
      archive- library search path.

           Future releases of ld may support similar functionality for
           other architecture families.

> and a:
> -m EMULATION to set the emulation

Here is the list of emulations for a multilib CodeSourcery toolchain
that supports armv4t, armv5t and thumb2 as multilib variants:

$ arm-none-linux-gnueabi-ld -V
GNU ld (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205
  Supported emulations:
   armelf_linux_eabi
   armelfb_linux_eabi

So clearly, the -m option does not allow to choose between the
different multilib variants.

In fact, I don't even see anything in ld that allows to select a
multilib variant. So the link should be using gcc, which then drives ld
(or more precisely collect2) by telling it to use this or that library.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] freetype: fix for multilib toolchain

[Thomas Petazzoni]

On Fri, 14 Jan 2011 13:47:54 +0100
Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:

> AFAIK, ld does not have an "-march" option (just looked at the man page).
> So I'd say that it is the freetype (and sshd?) package that needs to be fixed
> (and not BR) because they are using LDFLAGS wrong.

I clearly overlooked this, and I think you're correct.

So, as I said in another e-mail, I think ld does allows to choose
between different ld variants. So the link should always be done with
gcc, which then drives ld, giving it the correct path to the
appropriate libraries and runtime.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] freetype: fix for multilib toolchain

[Michael S. Zick]

On Fri January 14 2011, Thomas Petazzoni wrote:
> On Fri, 14 Jan 2011 13:47:54 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
> 
> > AFAIK, ld does not have an "-march" option (just looked at the man page).
> > So I'd say that it is the freetype (and sshd?) package that needs to be fixed
> > (and not BR) because they are using LDFLAGS wrong.
> 
> I clearly overlooked this, and I think you're correct.
> 
> So, as I said in another e-mail, I think ld does allows to choose
> between different ld variants. So the link should always be done with
> gcc, which then drives ld, giving it the correct path to the
> appropriate libraries and runtime.
> 

In my limited experience, that seems to be the most general solution;
call ld through the "gcc" front-end.

After all, that is one of the purposes of that front end driver, to
either process options or call the proper option processor helper.

That __should__ handle any vendor introduced changes to options.

Although there are option combinations that break the path generation
in the Code Sourcery, MIPS-4.3 tool chain build and I suppose that
could happen in other vendors/builds.

The "tuple-specific-gcc ..." call, 
minus input/output files, 
plus --print-multi-dir
should always output the resolved path for the full set of other options passed.

If it doesn't, then some combination of the other options are breaking the
path resolution (or the toolchain doesn't have libraries supporting that combination).

And the "tuple-specific-gcc -print-multi-lib" call should produce a list of
the available paths / option combinations.
Which comes into play with the fact that vendors are known to sometimes invent
their own naming scheme for the multi-library paths.

It might be possible to invent some sort of general purpose sanity test
based on this behavior to help in the situation when things break unexpectedly.

Mike

> Regards,
> 
> Thomas

[Buildroot] freetype: fix for multilib toolchain

[Matt Johnson]

>
> So, as I said in another e-mail, I think ld does allows to choose between
different ld variants.
> So the link should always be done with gcc, which then drives ld, giving
it the correct path to the appropriate libraries and runtime.
>

Sorry, perhaps I confused the issue.  It's not that -march needs to be
passed to LD, it's needed because of how the freetype makefile is designed
to use libtool.

From freetype-2.4.4/builds/unix/unix-cc.in:

# Library linking
#
LINK_LIBRARY = $(LIBTOOL) --mode=link $(CCraw) -o $@ $(OBJECTS_LIST) \
                          -rpath $(libdir) -version-info $(version_info) \
                          $(LDFLAGS) -no-undefined \
                          # -export-symbols $(EXPORTS_LIST)


Earlier in the file, they do this:

CCraw := $(CC)
CC    := $(LIBTOOL) --mode=compile $(CCraw)

I opened a bug with the FreeType team here:
https://savannah.nongnu.org/bugs/?32114

, suggesting that they pass the CFLAGS as part of CCraw, but one of their
lead devs suggested that just -march should be passed in the LDFLAGS.  Any
actual calls to LD would ignore the flag anyway.

Since FreeType is not updated anywhere near as often as BuildRoot, it seems
to make sense.

-Matt