Sat 09 Jul 2016 07:00:29 AM UTC, comment #18:
Thanks!
|
Sat 09 Jul 2016 05:11:51 AM UTC, comment #17:
Just I've checked jam building process on Mac OS X and
updated Jamfile to reflect current location of header files,
and ftmac.h would be included only for Mac OS & Mac OS X.
|
Fri 08 Jul 2016 05:51:16 PM UTC, comment #16:
Dear Ryan,
Thank you for testing! and sorry for your inconvenience.
I don't think my previous patch for Jamfile is important "show stopper" before 2.7.0, because it is not new bug. Werner, if you're very hurry, I would not say "please wait my fix for Jamfile".
|
Fri 08 Jul 2016 05:48:46 PM UTC, comment #15:
Here is the first draft of Jamfile patch which corrects the list of header files to be used for ftexport.sym.
However, this bug (#48417) does not exist in Jam building process, because
1) Originally Jam building process can make ftexport.sym manually (not automatically), but shared library would not be built by default, so the symbol list would not be used.
2) Jam building process has no switch to disable the compilation of the deprecated symbols in ftmac.c.
3) After 8502c98b15390a397de2d5826c9d8b017d7fc208 (2015-06-22, before 2.6.1), the header files of the source tree are moved, to prevent the namespace pollution. But "GenExportSymbols" rule in Jamfile did not reflect the change. As a result, Jam could not build ftexport.sym (apinames could not open include/ft2build.h).
Within 24 hours, I would be able to test the patch on my Mac OS X.
(file #37775)
|
Fri 08 Jul 2016 05:42:30 PM UTC, comment #14:
Thanks, this patch works for me.
|
Fri 08 Jul 2016 04:40:26 PM UTC, comment #13:
Dear Werner,
Indeed, I could not find "-export-symbols" stuffs in Jamfile.
But Jamfile seems to be designed to build apinames and make ftexport.sym.
I try to fix it...
I'm afraid ftexport.sym by Jamfile has been broken for a while,
because the headerss to be scanned are assumed to be placed under "include" and "include/cache". So I think no new regression was introduced recently :-)
|
Fri 08 Jul 2016 04:30:27 PM UTC, comment #12:
Hin-Tak has tested it successfully, thus closing.
|
Fri 08 Jul 2016 04:27:08 PM UTC, comment #11:
I think that neither Jam nor cmake is a problem, since they don't use the `-export-symbols' stuff from libtools.
So let's wait until users complain.
|
Fri 08 Jul 2016 04:21:38 PM UTC, comment #10:
The point keeping these deprecated symbols is for the binary compatibility.
When the time has come to introduce incompatible changes, we should drop them.
|
Fri 08 Jul 2016 03:25:08 PM UTC, comment #9:
These symbol have been deprecated since 2.3.2 which was released 2007-03-09, that is more than 9 years ago.
Deperecated symbols ought to be dropped at some point. Otherwise what is the point of deprecated symbols?
|
Fri 08 Jul 2016 03:05:12 PM UTC, comment #8:
Oh, I found that I've not fixed Jamfile. Taking a glance on
https://swarm.workshop.perforce.com/view/guest/perforce_software/jam/src/Jam.html
I found that there is no syntax to exclude some bits from a list, oh my god.
Maybe my fix would be more ugly in Jamfile.
BTW, for cmake - taking a glance on cmake files, I'm afraid
that the building by cmake do not control the symbol export...
|
Thu 07 Jul 2016 10:13:57 AM UTC, comment #7:
here is the tarball based on the git head,
which my proposed patch is applied.
(file #37750)
|
Thu 07 Jul 2016 09:49:10 AM UTC, comment #6:
Dear Werner,
Thank you for review. OK, I will commit and
make a tarball for easy test.
|
Thu 07 Jul 2016 09:46:31 AM UTC, comment #5:
Looks good, thanks! I think you can commit this.
|
Thu 07 Jul 2016 09:36:21 AM UTC, comment #4:
Dear Ryan and all,
Here is my first draft to improve exports.mk.
It excludes ftmac.h from the headers for apinames
by default, and include it when ftmac.c would be
included. I've tested on my legacy Mac OS X 10.8.
It works in both for the default (without ftmac) case
and "--with-old-mac-fonts" case.
(file #37747)
|
Wed 06 Jul 2016 02:53:16 PM UTC, comment #3:
Dear Ryan and all,
Sorry for inconveniences you experienced.
In this week, I'm absent from my Mac, but my current
analysis of the issue is following.
Although ftmac.c has the implementations of the symbols,
it would not be compiled at all under some configuration
(e.g. Carbon-free configuration dealing Mac OS X as usual
POSIX system). But, apinames scans all public headers
regardless with the configuration - so ftmac.h would be
scanned even if ftmac.c is not compiled, and the public
symbols in ftmac.h would be included in the symbol list
to be passed to ld.
I will try to fix exports.mk to ignore ftmac.h when ftmac.c
is not compiled, or, filter out the symbols declared in
ftmac.h. Please let me spend a week for this.
|
Wed 06 Jul 2016 01:54:27 PM UTC, comment #2:
These symbols do exist in ftmac.c.
|
Wed 06 Jul 2016 05:04:20 AM UTC, comment #1:
Thanks for the report.
The `apinames' auxiliary program generates a list of exported symbols from the public header files; this includes the file `ftmac.h', which defines the problematic symbols.
On my GNU/Linux box, symbols that do not exist in the library are simply ignored in ld's `-exported_symbols_list` argument. Obviously, ld on OS X doesn't do this.
Sigh. It's unfortunate that no Mac user has tested the build process after I've announced the usage of libtool's `export-symbols' option 6 weeks ago...
As a temporary solution you can manually remove the problematic symbols from the generated `libfreetype-symbols.expsym` file.
Toshiya-san, can you advise how to tackle this problem?
|
Tue 05 Jul 2016 09:36:08 PM UTC, original submission:
Hello, I'm the maintainer of freetype in MacPorts, and I'm unable to update our port to 2.6.4 because it fails to build as follows:
2.6.3 builds fine on the same system, which is OS X El Capitan 10.11.6 beta with Xcode 7.3.1 and Apple LLVM version 7.3.0 (clang-703.0.31).
|