On Tue, Feb 3, 2015 at 9:58 AM, Alexander Hansen
<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.
>
>>>> 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.
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
>
------------------------------------------------------------------------------
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
