Fails to build on OSX 10.8 #431

Closed
MikeMcQuaid opened this Issue Mar 14, 2013 · 17 comments

Projects

None yet

5 participants

@MikeMcQuaid

As of OSX 10.8 the FlatCarbon headers no longer exist so you need to use CarbonCore instead. These will still work on 10.6 and 10.7 at least (and possibly earlier versions too).

You can see the replacements we do in Homebrew to fix this problem here:
https://github.com/kballard/homebrew/blob/dec83c1acaf6e15ae95f62b3c2e37ba54170eae4/Library/Formula/fontforge.rb#L78

It would be great to get these changes upstreamed; let me know what I can do to help with this.

@MikeMcQuaid MikeMcQuaid referenced this issue in Homebrew/legacy-homebrew Mar 14, 2013
Closed

Fix FontForge compilation without 10.7 SDK #17910

@JoesCat
Contributor
JoesCat commented Mar 14, 2013

If you look in the latest configure.ac on github, take a look at approximately line 350 where it mentions tzset

a little bit after that point we could probably add something to this effect:
#ifdef __Mac
AC_CHECK_HEADER(CarbonCore/Files.h, [AC_DEFINE([_MAC_107],1,[Define if not using tzset.])])
#endif

The above if can be expanded to accept for possibilities.

Here is a definition for AC_CHECK_HEADER()
http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Generic-Headers.html

then in the files mentioned, or inc/carbon.h, whichever makes more sense, we could add

#ifdef __MAC_107
#include "CarbonCore/Files.h"
#else
#include "/Developer/Headers/FlatCarbon/Files.h"
#endif

#ifdef __MAC_107
#include "HIToolbox/CarbonEvents.h"
#else
#include "/Developer/Headers/FlatCarbon/CarbonEvents.h"
#endif

if configure.ac is fixed, then all that needs to happen is
sh autogen.sh
./configure
make

@MikeMcQuaid

Sure, whatever. I don't know enough about your buildsystem to suggest a fix except that we have already fixed it in Homebrew (as you can see from the link above). It's ok to not use FlatCarbon on older versions too.

@ultrasquid

Anything that can be done to make things easier for the package management
community, whether Homebrew, Macports, Fink or whatever else is out there
certainly sounds worth doing, and I am grateful for any advice that comes
from outside our core. If you happen upon any other problems and/or
solutions Mike, please don't hesitate to bring them up.

On Thu, Mar 14, 2013 at 1:00 PM, Mike McQuaid notifications@github.comwrote:

Sure, whatever. I don't know enough about your buildsystem to suggest a
fix except that we have already fixed it in Homebrew (as you can see from
the link above). It's ok to not use FlatCarbon on older versions too.


Reply to this email directly or view it on GitHubhttps://github.com/fontforge/fontforge/issues/431#issuecomment-14925711
.

Jason Pagura
zimbach at gmail dot com

@MikeMcQuaid

Thanks dude. Basically in the linked file inreplace is us just running sed over some of your files. If those could all be replaced with configure options that would be a massive improvement. Thanks!

@JoesCat
Contributor
JoesCat commented Mar 14, 2013

Hi @monkeyiq , @aktado, @davelab6,
I'm sure you'd know a better direction to go with this. I've more-or-less coded an idea here to make use of configure.ac.
I don't have a Mac, therefore can't test this - so someone else needs to try it and modify/fix it accordingly.

I don't know if you think this is better located in carbon.h, or something else (The homebrew above is in regards to Summer2012code).

--------------------------------- configure.ac ---------------------------------
index ecbda85..75c95ca 100644
@@ -281,6 +281,24 @@ if test x"${i_do_want_iconv}" = xyes; then
AC_CHECK_HEADERS([iconv.h])
fi

+# Check for Mac headers and set some flags accordingly, go latest -> oldest
+#ifdef __Mac
+# "CarbonCore/Files.h", "/Developer/Headers/FlatCarbon/Files.h",....
+AC_CHECK_HEADERS([CarbonCore/Files.h],[AC_DEFINE([_MAC_10_8FC],1,[Using 10.8SDK CarbonCore Files.h])],

  • [
  • AC_CHECK_HEADERS([/Developer/Headers/FlatCarbon/Files.h],[AC_DEFINE([_MAC_10_7FC],1,[Using 10.7SDK FlatCarbon Files.h])],
  •  [
    
  • ])
    +])

+AC_CHECK_HEADERS([HIToolbox/CarbonEvents.h],[AC_DEFINE([_MAC_10_8CE],1,[Using 10.8SDK CarbonEvents.h])],
+[

  • AC_CHECK_HEADERS([/Developer/Headers/FlatCarbon/CarbonEvents.h],[AC_DEFINE([_MAC_10_7CE],1,[Using 10.7SDK CarbonEvents.h])],
  • [
  • ])
    +])
    +#endif

#--------------------------------------------------------------------------

Checks for typedefs, structures, and compiler characteristics.

---------------------------- fontforge/macbinary.c ----------------------------
index d8fdb45..0e0acff 100644
@@ -37,6 +37,15 @@
#include "psfont.h"
#if __Mac

include <ctype.h>

+#ifdef _MAC_10_8FC
+#include <CarbonCore/Files.h>
+#else
+#ifdef _MAC_10_7FC
+#include </Developer/Headers/FlatCarbon/Files.h>
+#else
+/*# probably an older file here #include <somethingolder.h> */
+#endif
+#endif

include "carbon.h"

#else

include <utype.h>

----------------------------- fontforge/startui.c -----------------------------
index 5297691..647c05d 100644
@@ -53,6 +53,26 @@ extern uninm_names_db names_db; /* Unicode character names and annotations datab
#undef GTimer

#ifdef __Mac
+
+#ifdef _MAC_10_8FC
+#include <CarbonCore/Files.h>
+#else
+#ifdef MAC_10_7FC
+#include </Developer/Headers/FlatCarbon/Files.h>
+#else
+/
# probably an older file here #include <somethingolder.h> */
+#endif
+#endif
+#ifdef _MAC_10_8CE
+#include <HIToolbox/CarbonEvents.h>
+#else
+#ifdef MAC_10_7CE
+#include </Developer/Headers/FlatCarbon/CarbonEvents.h>
+#else
+/
# probably an older file here #include <somethingolder.h> */
+#endif
+#endif
+
extern void setup_cocoa_app();
#endif

------------------------------- gutils/giomime.c -------------------------------
index ae64854..041989a 100644
@@ -69,6 +69,15 @@ unichar_t fontsnf[] = { 'a','p','p','l','i','c','a','t','i','o','n','/','x','-',
//unichar_t fonttexfm[] = { 'a','p','p','l','i','c','a','t','i','o','n','/','x','-','t','e','x','-','t','f','m', '\0' }; /* *.tfm */

#ifdef __Mac
+#ifdef _MAC_10_8FC
+#include <CarbonCore/Files.h>
+#else
+#ifdef _MAC_10_7FC
+#include </Developer/Headers/FlatCarbon/Files.h>
+#else
+/*# probably an older file here #include <somethingolder.h> */
+#endif
+#endif
#include <carbon.h>
#define CHR(ch1,ch2,ch3,ch4) (((ch1)<<24)|((ch2)<<16)|((ch3)<<8)|(ch4))

@JoesCat
Contributor
JoesCat commented Mar 14, 2013

Looking at the above - Seems it's better to put it on github versus a comments:
JoesCat@47a42a3

@MikeMcQuaid

Looks cool but want to remove the 10.8/10.7 references as this is tied to Xcode versions too I think. I'd just name the macros something with CARBON_CORE and FLAT_CARBON. Nice work!

@JoesCat
Contributor
JoesCat commented Mar 15, 2013

It's a start. Fine suggestions.
I'll wait for someone to chime-in, going further needs the help of someone willing to try it who also runs a mac so we know these sort of edits work....etc,etc,etc... ;-)

Looking at the homebrew mods on your URL, there is a possibility of also importing some of the flags you add or modify and also encasing them inside the same ifdef or in another ifdef group within configure.ac

@MikeMcQuaid

@khaledhosny Very good points there; that's exactly the problem here.
@JoesCat Yes, that seems like a good idea. I've got a Mac with VMs for 10.5/6/7/8 so can test stuff once someone has code working. Are there no FontForge developers with Macs?

@ultrasquid

I have Macs, but I'm hardly a developer. Just a concerned end-user cum
beta-tester. I haven't figured out the magic spell to make FF compile on a
Mac OS X, but I was able to do it under Ubuntu.

On Fri, Mar 15, 2013 at 3:06 AM, Mike McQuaid notifications@github.comwrote:

@khaledhosny https://github.com/khaledhosny Very good points there;
that's exactly the problem here.
@JoesCat https://github.com/JoesCat Yes, that seems like a good idea.
I've got a Mac with VMs for 10.5/6/7/8 so can test stuff once someone has
code working. Are there no FontForge developers with Macs?


Reply to this email directly or view it on GitHubhttps://github.com/fontforge/fontforge/issues/431#issuecomment-14952761
.

Jason Pagura
zimbach at gmail dot com

@ultrasquid

Test builds for Mac by @monkeyiq are at
http://fuuko.libferris.com/osx/packages/

On Fri, Mar 15, 2013 at 3:29 AM, Jason Pagura zimbach@gmail.com wrote:

I have Macs, but I'm hardly a developer. Just a concerned end-user cum
beta-tester. I haven't figured out the magic spell to make FF compile on a
Mac OS X, but I was able to do it under Ubuntu.

On Fri, Mar 15, 2013 at 3:06 AM, Mike McQuaid notifications@github.comwrote:

@khaledhosny https://github.com/khaledhosny Very good points there;
that's exactly the problem here.
@JoesCat https://github.com/JoesCat Yes, that seems like a good idea.
I've got a Mac with VMs for 10.5/6/7/8 so can test stuff once someone has
code working. Are there no FontForge developers with Macs?


Reply to this email directly or view it on GitHubhttps://github.com/fontforge/fontforge/issues/431#issuecomment-14952761
.

Jason Pagura
zimbach at gmail dot com

Jason Pagura
zimbach at gmail dot com

@JoesCat
Contributor
JoesCat commented Mar 16, 2013

On March 15, 2013 03:06:51 AM Mike McQuaid wrote:

@khaledhosny Very good points there; that's exactly the problem here.
@JoesCat Yes, that seems like a good idea. I've got a Mac with VMs for
10.5/6/7/8 so can test stuff once someone has code working.

Glad you both agree here. Looking at the current code we have now, seems we
already have that thanks to @aktado a while ago. Feedback is appreciated.

Are there no FontForge developers with Macs?

A bit of a mixed bag.
Ben does have it getting built on a machine for others to use, and we have
several users willing to get a couple of bumps and bruises while riding the
bleeding edge, but in terms of building from scratch, I think we are still
having issues with this step and therefore the reliance/dependence on
someone building it for them.
It may be a bit too advanced?

Currently we're doing
sh autogen.sh
./configure
make

...but that works okay for linux, but probably needs adjustment for Mac.
Is this okay? or do we need some adjustments?

@MikeMcQuaid

@JoesCat That should be fine for Mac; your autogen/configure/make should detect OSX and do the right thing. Regardless, this issue isn't too complicated, it's literally just a matter of fixing header locations. We don't need to do anything with the buildsystem at all for this.

@JoesCat
Contributor
JoesCat commented Mar 18, 2013

@davelab6 , I think this could probably be considered closed but it really needs the acknowledgement of someone who is actually building FontForge on a Mac to say we're okay with what we have right now since looking at what we have right now, inc/carbon.h already refers to carbon/carbon.h while the bug mentioned in homebrew is referring to the summer2012-b downloadable version on sourceforge.

I believe Mike delisted from this bug to cut down on the noise factor on his end, so it's up to us to resolve this as fixed or not.

@MikeMcQuaid

@JoesCat Is there a commit that closes this?

@JoesCat
Contributor
JoesCat commented Mar 18, 2013

On March 18, 2013 02:36:18 PM Mike McQuaid wrote:

@JoesCat Is there a commit that closes this?

Glad to see you are here, so I guess you meant the other list. :-)

Looking at inc/carbon.h seems we've been okay for 3 months now.
https://github.com/fontforge/fontforge/blob/master/inc/carbon.h

I don't know if we're done and good to go, or if we still need something
else - was hoping someone running a Mac could verify.

Thinking about this - I kept referring to sh autogen.sh, but we should be
okay with just ./autogen.sh. The reason I kept mentioning sh autogen.sh is
having seen other problems with some other script.

Are you okay with
./autogen
./configure
make
su
make install
exit

the su and exit is for linux, since root and user are treated under
different permissions, and once again, I can't say how it works for Mac.

If you're willing to build with what we have right now then great, unless
you need some sort of release package before testing.

@davelab6 davelab6 closed this Aug 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment