GNOME Bugzilla – Bug 576615
[GEGL] These patches are required for successful vendor compiles on non-linux machines
Last modified: 2014-02-05 10:08:50 UTC
Please describe the problem: It is very difficult to compile gegl unless you are using gcc and gmake with the GNU coreutils and ruby, on a linux host. With the attached patches I was able to successfully build everything with the vendor compilers on these 27 architectures: SuSE SLES 10 (x86_64 and i686); Redhat RHEL3, RHEL4 and RHEL5 (x86_64 and i686); Redhat 9 and RHEL 2.1 (i686); Solaris 10 (x86 and sparc); Solaris 2.6, 7, 8 and 9 (sparc); AIX 4.3.3, 5.1, 5.2, 5.3 and 6.1 (powerpc); HPUX 11.31 (ia64); HPUX 11.23 (pa-risc and ia64); HPUX 10.20, 11.0 and 11.11 (pa-risc); IRIX 6.5 (mips). (I was unable to get a working build on OSF 5.1 and RH linux 7.1, and will post to the mailing list separately for help on this). Here is a list of some of the problems solved by the attached patches, which would otherwise prevent proper compilation by one or more vendor C compilers: * use gnulib for systems that don't have full GNU environment * support shl_load -ldl library loader on HPUX * remove extraneous trailing commas from *CONVERSION mcros * automake INCLUDES is deprecated, use AM_CPPFLAGS * support srcdir != builddir builds * use automake source file inference in tests/ * variadic macros are not portable * don't use non-constant struct initializers * don't use the MSB of a signed integer type in an enum * don't use C++ comments * rewrite xml_instert.sh not to rely on GNU coreutils * for gnulib and autoconf to work properly, every .c file needs to #include "config.h" before anything else! Steps to reproduce: 1. go to a non-linux machine 2. try to compile git master gegl with the vendor compiler Actual results: compilation fails in most cases, or else if gegl does compile, all the tests fail catastrophically Expected results: everything works the same as with gcc on linux Does this happen every time? yes Other information:
Created attachment 131289 [details] quilt series file put this file and all other attachments into a patches directory, and apply with 'quilt push all' alternatively, apply each patch manually in the order shown in the series file
Created attachment 131290 [details] [review] config.h needs to be included at the top of every .c file in an autoconf project
Created attachment 131292 [details] [review] older aix and irix compilers choke on trailing commas in enum decls
Created attachment 131294 [details] [review] enum values must be less than INT_MAX (sign bit is illegal)
Created attachment 131295 [details] [review] some vendor C compilers choke on C++ comments
Created attachment 131296 [details] [review] some vendor compilers can't compile non-constant elements of compound struct initializers
Created attachment 131297 [details] [review] some vendor compilers choke on compound declaration casts
Created attachment 131298 [details] [review] variadic macros are non-portable, use a glib like configure-time scheme falling back to variadic functions
Created attachment 131299 [details] [review] null-statements caused by trailing semi-colons are non-portable
Created attachment 131300 [details] [review] support hpux use of dsos with .sl suffixes
Created attachment 131301 [details] [review] the Makefile.ams shouldn't use deprecated automake features, or redundant declarations This patch removes most of the warnings and errors thrown by automake-1.10.1, and the smaller Makefile.ams are easier to read It doesn't address the use of gmake wildcard extensions, so you still can't use a vendor make to build gegl.
Created attachment 131302 [details] [review] rewrite xml-insert.sh in portable bourne-shell
Created attachment 131303 [details] [review] don't try to pass gcc flags to vendor compilers some vendor compilers warn about unknown flags but otherwise compile (noisily, with a warning for every unknown flag on every compilation unit) since we know these are gcc flags, only see whether they work when we're compiling with gcc
Created attachment 131304 [details] [review] unsized arrays are not supported by many vendor compilers
Created attachment 131305 [details] [review] don't try to return a value from a void function
Created attachment 131306 [details] [review] changes to Makefile.am and configure.ac to support gnulib modules in the next patch
Created attachment 131307 [details] [review] for completeness only, you should probably ignore this these changes are for our in-house packaging system, and require a patched libtool... but maybe useful if subsequent patches don't apply correctly with this one missing. mostly useless :)
Created attachment 131308 [details] [review] gnulib modules required for portable compilation likely you only need gnulib-cache.m4 from here to see which modules I needed, the patch was with our own slightly patched gnulib. I've attached this for completeness, since it is part of my working, ported and tested gegl tarball. Most likely, you should fetch your own gnulib from git and: gnulib-tool --import extensions fpieee floorf pathmax
Created attachment 131309 [details] files generated by modern autotools bzip2 compressed patch file again, just for completeness to show you what my working aclocal.m4, config.h.in etc look like using stock autoconf-2.63 and automake-1.10.1 with our own lightly patched libtool-1.5.x You should probably 'autoreconf -fvi' with the latest/blessed versions of those tools yourself rather than apply this patch
(In reply to comment #8) > Created an attachment (id=131298) [edit] > variadic macros are non-portable, use a glib like configure-time scheme falling > back to variadic functions This patch does not apply cleanly any longer so it needs to be update. I think the best would be to wait for the git migration to be complete and then we can handle the distribution of commits using the git facilities The patches before that are commited now.
(In reply to comment #20) > (In reply to comment #8) > > Created an attachment (id=131298) [edit] > > variadic macros are non-portable, use a glib like configure-time scheme falling > > back to variadic functions > > This patch does not apply cleanly any longer so it needs to be update. I think > the best would be to wait for the git migration to be complete and then we can > handle the distribution of commits using the git facilities Gegl seems to get more code churn than babl, and some of my original patches had bitrotted since I posted them. I've updated from git and regenerated everything now. The ones that needed updates (plus a new G_STRFUNC patch to match my babl submissions) are all attached below, along with a new series file.
Created attachment 131664 [details] series put this file and all other attachments into a patches directory, and apply with 'quilt push all' alternatively, apply each patch manually in the order shown in the series file
Created attachment 131665 [details] [review] variadic-macros.patch variadic macros are non-portable, use a glib like configure-time scheme falling back to variadic functions
Created attachment 131666 [details] [review] null-statements.patch null-statements caused by trailing semi-colons are non-portable
Created attachment 131667 [details] [review] hpux-plugins.patch support hpux use of dsos with .sl suffixes
Created attachment 131668 [details] [review] modernize-makefile-ams.patch The Makefile.ams shouldn't use deprecated automake features, or redundant declarations. This patch removes most of the warnings and errors thrown by automake-1.10.1, and the smaller Makefile.ams are now easier to read It doesn't address the use of gmake wildcard extensions, so you still can't use a vendor make to build gegl.
Created attachment 131669 [details] [review] portable-xml-insert.patch rewrite xml-insert.sh in portable bourne-shell
Created attachment 131670 [details] [review] gcc-flags-vs-vendor-compilers.patch don't try to pass gcc flags to vendor compilers some vendor compilers warn about unknown flags but otherwise compile (noisily, with a warning for every unknown flag on every compilation unit) since we know these are gcc flags, only see whether they work when we're compiling with gcc
Created attachment 131671 [details] [review] unsized-arrays.patch unsized arrays are not supported by many vendor compilers
Created attachment 131672 [details] [review] void-returns.patch don't try to return a value from a void function (it chokes some picky vendor compilers)
Created attachment 131673 [details] [review] G_STRFUNC.patch avoid the need for CPPFLAGS='-D__FUNCTION__="unknown"' on some vendor compilers
Created attachment 131674 [details] [review] dont-assume-GNU-runtime.patch `ls -1' and `diff -U 50' are GNUisms. The -1 isn't necessary in any case, and I changed -U to -C just to get it working... if you need unified diffs, then a configure time check for GNU diff (possibly called gdiff) in PATH will be needed instead of this easy fix.
Created attachment 131675 [details] [review] gnulib-prep.patch changes to Makefile.am and configure.ac to support gnulib modules in the (generated) gnulib.patch
Created attachment 131676 [details] [review] tww.patch for completeness only, you should probably ignore this these changes are for our in-house packaging system, and require a patched libtool... but maybe useful if subsequent patches don't apply correctly with this one missing. mostly useless :)
Created attachment 131677 [details] [review] gnulib.patch gnulib modules required for portable compilation likely you only need gnulib-cache.m4 from here to see which modules I needed, the patch was with our own lightly modified gnulib. I've attached this for completeness, since it is part of my working, ported and tested gegl tarball. Most likely, you should fetch your own gnulib from git and: gnulib-tool --import extensions fpieee floorf pathmax
Created attachment 131678 [details] auto.patch.bz2 files generated by modern autotools bzip2 compressed patch file again, just for completeness to show you what my working aclocal.m4, config.h.in etc look like using stock autoconf-2.63 and automake-1.10.1 with our own lightly patched libtool-1.5.x You should probably 'autoreconf -fvi' with the latest/blessed versions of those tools yourself rather than apply this patch
(In reply to comment #33) > Created an attachment (id=131675) [edit] > gnulib-prep.patch > > changes to Makefile.am and configure.ac to support gnulib modules in the > (generated) gnulib.patch > Got a problem with this for GEGl as well, same build problem as for babl. I also had to re-add exr_load_la_SOURCES = exr-load.cpp because automake failed otherwise, probably because it looked for .c not a .cpp. The preceding patches have been commited. Could you look into this gnulib stuff please?
I just noted that the changes to test/Makefile.am does not run those two tests by default when doing a make check any longer which is of course pretty sever. Could you look into that too please? All tests should be run on a make check. If I would have noticed this before commiting the Makefile.am patch, I wouldn't have commited it :/
(In reply to comment #37) > (In reply to comment #33) > > Created an attachment (id=131675) [edit] > > gnulib-prep.patch > > > > changes to Makefile.am and configure.ac to support gnulib modules in the > > (generated) gnulib.patch > > > > Got a problem with this for GEGl as well, same build problem as for babl. > > I also had to re-add > > exr_load_la_SOURCES = exr-load.cpp > > because automake failed otherwise, probably because it looked for .c not a > .cpp. > > The preceding patches have been commited. Could you look into this gnulib stuff > please? Same solution as babl, pasted below (more-or-less): This patch needs to be applied at the same time as gnulib.patch... I kept them separate because gnulib-prep.patch are the edits that I made to GEGL files manually, and gnulib.patch itself is the files that are automatically generated by gnulib-tool. Depending on your commit policy, you may or may not keep automatically generated files under version control. Normally, projects that use gnulib for portability commit m4/gnulib-cache.m4 only... this allows people to run 'gnulib-tool' on a freshly checked out tree and autogenerate sources and Makefile.am for the right modules. Remember also that my attached gnulib.patch contains the automatically generated files from our lightly patched in-house gnulib, so rather than applying that directly, I would recommend pulling the current git master of gnulib onto your dev-machine, and running gnulib-tool from there: $ cd $HOME/Devo $ git clone git://git.savannah.gnu.org/gnulib.git gnulib--master--0 $ PATH=$HOME/Devo/gnulib--master--0:$PATH $ cd $HOME/Devo/GEGL--master--0 $ patch -p0 < patches/gnulib-prep.patch $ gnulib-tool --import extensions fpieee floorf pathmax At this point everything will build again after an autoreconf (as before, I attached a patch that contains the generated files from our lightly patched in-house autoconf,automake and libtool incase you want to compare to your own output if things aren't behaving as you'd expect). Thanks again Martin for wading through these for me!
Created attachment 131882 [details] series New series file to match unapplied patches against current git master.
Created attachment 131883 [details] [review] use-ruby-from-PATH.patch Don't assume #!/usr/bin/ruby, call ruby from PATH in Makefiles.
Created attachment 131884 [details] [review] run-test-cases-fix.patch Fixes breakage in earlier modernize-makefile-ams.patch
(In reply to comment #38) > I just noted that the changes to test/Makefile.am does not run those two tests > by default when doing a make check any longer which is of course pretty sever. > Could you look into that too please? All tests should be run on a make check. > If I would have noticed this before commiting the Makefile.am patch, I wouldn't > have commited it :/ G'ah.. thought they were link tests, sorry! Fixed by run-test-cases-fix.patch attached above. (Subsequent patches in the series file apply with fuzz, so I didn't reattach.)
Gary, just wanted to tell you about this fix I had to make: 2009-04-11 Martin Nordholts <martinn@svn.gnome.org> * gegl/Makefile.am: Move the libgegl build libs from LIBS to _LIBADD because dependency tracking doesn't seem to work otherwize. That is, changes in gegl/operation/liboperation.la doesn't cause a rebuild of libgegl-@GEGL_API_VERSION@.la. since it is a rather server building problem.
I am working towards 0.1.0 and don't consider the last parts of this a blocker.
No sign of Gary for a while, so let's move this to milestone 'Future' so we can enjoy the site with no bugs on the 0.1.0 milestone list for GEGL.
What remains to be done is to use the gnulib library in the same way M4 does it, see: http://www.mail-archive.com/gegl-developer@lists.xcf.berkeley.edu/msg00582.html and the messages after that.
Hi Martin, Sorry for the silence... I've been trying to get glibmm/cairomm/gtkmm to compile on all my machines recently. This isn't forgotten, but I won't be able to get back to it for a few more weeks.
There are still some patches in here, are they still necessary?