bugThe FreeType Project - Bugs: bug #58051, Setting CC and...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58051: Setting CC and MAKEFLAGS="CC=..." to gcc breaks freetype build unexpectedly

Submitter:  - <_186337>
Submitted:  Thu 26 Mar 2020 02:00:08 PM UTC
   
 
Severity:  3 - Normal Item Group:  Hack required
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.2

Wed 08 Apr 2020 08:02:44 AM UTC, comment #5: 

My bad, typo'ed again, I meant ./configure --host=x86_64-w64-mingw32 and CC=x86_64-w64-mingw32-gcc of course. In any case, it works!

- <_186337>
Wed 08 Apr 2020 08:00:59 AM UTC, comment #4: 

I just tested freetype2's revision 11beee855e29757a07320fd60e85de2e8da4e037 with a native linux 64bit build with gcc with CC=gcc, and a cross-compile build with ./configure --host=x86_64-w64 and CC=x86_64-w64-mingw32, both of which used to fail, and both work for me now.

So as far as I can tell the fix works! Thanks!

- <_186337>
Wed 08 Apr 2020 07:07:12 AM UTC, comment #3: 

Fixed in git.  Thanks for the report, please test!

Werner LEMBERG <wl>
Group administrator
Thu 26 Mar 2020 04:42:38 PM UTC, comment #2: 

Thanks for submitting the report; will have a look soon.

Werner LEMBERG <wl>
Group administrator
Thu 26 Mar 2020 02:01:46 PM UTC, comment #1: 

Correction: sorry, the second working command should have looked like this:


bash ./autogen.sh && ./configure --with-zlib=no --with-bzip2=no
--with-png=no --with-harfbuzz=no && make


- <_186337>
Thu 26 Mar 2020 02:00:08 PM UTC, original submission:  

Since I so far didn't get a mailing list response indicating this is intentional in some way, I hope it's ok for me to make a ticket:

Freetype's build scripts appear to break when specifying the compiler via CC & MAKEFLAGS that it was going to use anyway, like this:


bash ./autogen.sh && ./configure --with-zlib=no --with-bzip2=no
--with-png=no --with-harfbuzz=no && CC=gcc MAKEFLAGS=" CC=gcc" make


This eventually gives this output:


libtool:   error:
'/home/ellie/Develop/myprj/vendor/freetype2/objs/ftsystem.lo' is not a
valid libtool object
make: *** [config.mk:55:
/home/ellie/Develop/myprj/vendor/freetype2/objs/libfreetype.la] Error 1


While this command without CC being set works:


bash ./autogen.sh && ./configure --with-zlib=no --with-bzip2=no
--with-png=no --with-harfbuzz=no && CC=gcc MAKEFLAGS=" CC=gcc"


(runs fine to the end with exit code 0 and valid .a/.so results)

This is a problem when calling the freetype build nested from an external Makefile, e.g. I use this to build a freetype copy from latest source for static linking and it took me quite a while to track this down. I worked around this by explicitly unsetting CC and MAKEFLAGS when invoking freetype, but I think this hack shouldn't be required: any other software I build like this didn't mind CC being set to what it was going to use anyway.

Does freetype maybe set CC to something that adds in flags, like "gcc -option", and forgets to do so when it's already set? That seems like something worth fixing then.

- <_186337>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by _186337 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-04-08 wl StatusNone Fixed
        Assigned toNone wl
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.2

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code