bugThe FreeType Project - Bugs: bug #32114, cflags missing in makefile

 
 

bug #32114: cflags missing in makefile

Submitted by:  None
Submitted on:  Wed 12 Jan 2011 06:24:59 PM UTC  
 
Severity: 3 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: suzuki toshiya <mpsuzuki>Open/Closed: Closed
Planned Release: 2.4.5

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 15 Jan 2011 04:58:29 AM UTC, comment #8:

Thank you for the proposal to BuildRoot project.
I wish BuildRoot will be improved to accept
you patch to specify CFLAGS & LDFLAGS separately.

Also I've improved configure script for latest
GIT revision, to copy -march=XXX and -mcpu=XXX
options to LDFLAGS automatically if they are
included in CFLAGS but not in LDFLAGS.
If BuildRoot refuses your patch, or there are users
sticking to legacy BuildRoot before your patch,
newer revision of FreeType2 will help.

Here I close this bug, thank you very much!

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Fri 14 Jan 2011 03:25:51 AM UTC, comment #7:

Looks like I was typing my comment right when you pasted yours, so I didn't see your last one.

I agree with you about most of that. However, it seems in this case, the only reason -march is needed during linking is so that a multilib toolchain can link with the proper c library. So I don't think all of the rest is neccessary. The other flags are really about compiler optimizations, so they probably don't belong with the linker IMHO.

-Matt

Anonymous
Fri 14 Jan 2011 03:21:04 AM UTC, comment #6:

That worked - passing the march in the LDFLAGS during configure.

I will post a patch with the Buildroot team. No change is needed to FreeType.

You can close this bug.

Thanks for your help!
-Matt

Anonymous
Fri 14 Jan 2011 03:19:48 AM UTC, comment #5:

OK, I understand there is a limitation of developer
environment. I wish if the maintainer of BuildRoot
can improve it, but I will insert a hook into configure.raw
to duplicate architecture specification flags like "-march"
"-mcpu" from CFLAGS to LDFLAGS, as far as LDFLAGS
does not have their own specification.

In fact, similar hook is already existing in configure.raw,
for Mac OS X. Apple had ever published a document
to specify SDK version to CFLAGS but not to LDFLAGS,
and some developer were trapped by the linker's warning
about incompatible object files are to be linked.

One of my anxiety is: now I think "-arch" "-mcpu" "-march"
are the flags to be duplicated from CFLAGS to LDFLAGS.
Or, if something like "-msoft-float" should be duplicated too,
I will revise configure.raw duplicate all "-mXXX" flags.
Is there anything else? For example, CFLAGS may include
the optimization flags like "-fno-builtin", "-fno-implement-inlines",
they should be duplicated too? According to gcc manuals,
these options may change the link result.

And, could you give me the comment about "freetype-config"
and "freetype2.pc" should reflect the architecture-specification
flags? In 32-bit/64-bit multilib cases, like amd64/i386, most
GNU/Linux distributions separate these pkg-config databases,
so the architecture-specification flags are configured before
loading pkg-config database, thus we don't have to need to
duplicate "-m32" or "-m64" flags into them. But we don't know
if more detailed-classified multilib environment separate these
files for each architectures. If it's difficult to conclude at once
or you have no trouble about them, the update of these files
will be postponed.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Thu 13 Jan 2011 09:20:40 PM UTC, comment #4:

Well, since I'm using BuildRoot (http://buildroot.uclibc.org/), I'm at the mercy of how they do things. Currently, -march is only passed in the CFLAGS. BuildRoot does let you customize things, so I may be able to pass it in LDFLAGS as well, but right now it's not in there.

I think this may be a good approach, as it appears just to be the linker that's off. It's linking in the wrong libraries (because of the multilib toolchain).

I'll work on BuildRoot's makefile for FreeType and see if I can do it in there so it doesn't need to be changed here. I'll post back in a day or two.

Thanks,
Matt

Anonymous
Thu 13 Jan 2011 05:44:11 PM UTC, comment #3:

Sorry for lated response. Could you tell me your preferred
method how to pass the architecture specification flag during
configuration?

One of the easiest solution to pass "-march=XXX" flag to
libtool in compiling & linking phase is that setting both of
CFLAGS and LDFLAGS environment during the execution
of configure script. CFLAGS & LDFLAGS are copied to
unix-cc.mk, so executing configure aslike

env CFLAGS="-march=XXX" LDFLAGS="-march=XXX" ./configure ...

is OK. no need to set these environment when you run
"make".

However, these flags are not copied to freetype-config
and freetype2.pc. If they are required to be copied,
some improvement is needed.

suzuki toshiya <mpsuzuki>
Project AdministratorIn charge of this item.
Wed 12 Jan 2011 09:40:54 PM UTC, comment #2:

The actual problem is that since no architecture flag is passed into libtool during linking (further down on line 109 in the same file), the CodeSourcery multilib toolchain I'm using reverts to the default architecture - which is armv5te. That builds instructions that don't exist on armv4t, so I get illegal instruction errors.

Perhaps it would be better to pass cflags to the linker - or perhaps I should just pass the -march=armv4t flag and ignore the rest of the cflags?

I will yield to Toshiya-san's expertise.

Thanks,
Matt

Anonymous
Wed 12 Jan 2011 06:47:14 PM UTC, comment #1:

This fix is wrong, I believe. AFAIK, it should work directly from the command line. I've assigned your report to Toshiya-san since he has taken care of cross compiling in the past.

Werner LEMBERG <wl>
Project Administrator
Wed 12 Jan 2011 06:24:59 PM UTC, original submission:

Hello. I have built freetype from source as part of my BuildRoot setup. I am targeting an embedded system with an armv4t based processor. I use a toolchain from CodeSourcery, which is a multi-lib toolchain that targets various architectures. It's important to pass the -march=armv4t on the cflags to all instances of CC for the target processor so the toolchain picks the right library.

In freetype's /builds/unix/unix-cc.in file, line 91 has an isolated command labeld "CCraw". I'm not sure what the intention here is, but since no cflags are passed with CCraw, the toolchain picks the wrong library. The net result is that I get "illegal instruction" errors when using freetype on my device.

It works if I pass the cflags, but I don't know if this has other unintended consequences or not, since I'm not familiar with the development of this project.

In other words, changing:

CCraw := $(CC)

to

CCraw := $(CC) $(CFLAGS)

solves the problem for me.

Please let me know if this is a reasonable fix, and if so - please commit it to your source so the next release will have it automatically.

Thanks.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mpsuzuki (Posted a comment)
  • -unavailable- added by wl (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 15 Jan 2011 07:17:51 AM UTCwlPlanned ReleaseNone=>2.4.5
    Sat 15 Jan 2011 04:58:29 AM UTCmpsuzukiStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 12 Jan 2011 06:47:14 PM UTCwlAssigned toNone=>mpsuzuki

    Back to the top


    Powered by Savane 3.1-cleanup