> On Feb 3, 2015, at 8:23 AM, Jack Howarth <howarth.at.f...@gmail.com> wrote:
>
> On Tue, Feb 3, 2015 at 9:58 AM, Alexander Hansen
> <alexanderk.han...@gmail.com <mailto:alexanderk.han...@gmail.com>> wrote:
>> ^ I’m not updating the revision for a FATAL build-time issue and forcing
>> people who have a working setup to rebuild this giant hunk of software.
>> Lots of folks have fewer than 8 cores, just like me, and don’t want to tie
>> up multiple hours on an unnecessary rebuild.
>
> I don't see why these issues require a revision bump as we are only
> fixing build failures.
>
_You_ bumped it in your diff. Actually I am going to bump it, though, due to a
.deb metadata update.
>>
>>>>> Maintainer: Alexander Hansen <alexkhan...@users.sourceforge.net>
>>>>>
>>>>> BuildDepends: <<
>>>>> @@ -181,6 +181,10 @@
>>>>>
>>>>> # Patch configure not to link like Puma on Yosemite
>>>>> perl -pi -e 's/(10\.\[012\])\*/\1\,.\*/' configure
>>>>> +
>>>>> + # Fix X11 include
>>>>> + perl -pi -e
>>>>> 's,X11_INCFLAGS=\"\$x_includes\",X11_INCFLAGS=\"-I\$x_includes\",'
>>>>> configure
>>>>> + perl -pi -e 's,\$XTRA_CXXFLAGS \$FT2_CFLAGS,\$XTRA_CXXFLAGS
>>>>> \$FT2_CFLAGS \$X11_INCFLAGS,' configure
>>>>> <<
>>>>>
>>
>> ^ Looks like it should be fine, but I’ll want to check for myself.
>>
>> I didn’t initially see this yesterday because your reports didn’t specify
>> the LITERAL package name, i.e octave364-x11; I was working with the
>> “octave364” variant. The octave variants without -x11 in their name don’t
>> tickle the freetype2 issue because it’s associated with fltk-x11.
>
> I am seeing the configure failure of...
>
> /usr/X11/include/ft2build.h:56:10: fatal error:
> 'freetype/config/ftheader.h' file not found
>
> with the stock octave364 build on 10.7. Note that the non-X11 variant
> does oddly link against freetype219...
>
> % otool -L /sw/lib/octave/3.6.4/liboctinterp.1.dylib | grep freetype219
> /sw/lib/freetype219/lib/libfreetype.6.dylib (compatibility
> version 17.0.0, current version 17.1.0)
>
> and fails because it places of -I/usr/X11/include before the
> -I/usr/include/freetype2 which allows the X11 copy of
> /usr/X11/include/ft2build.h to be found before the one in fink's
> freetype219 at /sw/include/freetype2/ft2build.h.. It is puzzling that
> octave364 is building freetype support in the absence of X11 support
> though.
>
>>
>>>>> GCC: 4.0
>>>>> @@ -229,7 +233,8 @@
>>>>>
>>>>> osversion=`uname -r | cut -d. -f1`
>>>>> export CFLAGS='-O3 -MD'
>>>>> - export CXXFLAGS="-O3 -MD -I/usr/X11/include"
>>>>> + #export CXXFLAGS="-O3 -MD -I/usr/X11/include"
>>>>> + export CXXFLAGS="-O3 -MD”
>>
>> ^ breaks the build for all octave-3.6.4 variants on anything later than 10.7
>> because something can’t find Xlib.h, even when the configure script is given
>> X11 paths explicitly. It was probably relying on the old /usr/include/X11
>> convenience symlink
>
> My previous patch assumed every Makefile.in was using $AM_CXXFLAGS for
> the cxx compile flags. Perhaps we only need to explicitly add usages
> of $X11_INCFLAGS to a limited number of Makefile.in to solve this.
> Alternatively it might just be easier just to go back to flag-sort as
> I did in openmotif4. In that case, there were endless Makefiles which
> required multiline flag assignments to be re-ordered to eliminate the
> leakage of the X11's freetype headers.
>
No, I meant that simply taking out -I/usr/X11/include breaks the build,
irrespective of whether your patch was in use or not.
Your patch didn’t work for me on 10.10, anyway, because something couldn’t find
ft2build.h. There were no -I/sw/include/freetype2 in the compiler line at that
point, so it’s understandable. Using
SetCXXFLAGS: -03 -MD -I%p/include/freetype2 -I/usr/X11/include
(and getting rid of the initial setting of that variable in the CompileScript)
appears to do the trick.
> The universal failure of the InfoTest when run as fink-bld is the most
> serious issue and appears to require those plotting tests that try to
> access the screen to be disabled.
>
>>
>> --
>> Alexander Hansen, Ph.D.
>> Fink User Liaison
I disagree completely. Fatal errors for _everybody_ building the package are
more important than errors which only occur when people build in maintainer
mode.
That’s a completely separate issue. And none of this is going to change the
rate at which I do any fixes. They’ll happen when I’m satisfied that I like
the solution, and that
--
Alexander Hansen, Ph.D.
Fink User Liaison
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
