GNOME Bugzilla – Bug 574705
[BABL] These patches are required for successful vendor compiles on non-linux machines
Last modified: 2014-02-05 10:56:18 UTC
Please describe the problem: It is very difficult to compile babl-0.0.22 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, and pass all but one test (failure output below) on these 30 architectures: SuSE SLES 10 (x86_64 and i686); Redhat RHEL3, RHEL4 and RHEL5 (x86_64 and i686); Redhat 7.1, 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); Tru64 Unix 5.1 (ev5). 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: * build the extensions with libtool * support '.sl' shared library ext on HPUX * use correct includedir entry in babl.pc * use gnulib stdint.h for systems that don't have one * 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/ * pregenerate changelog.rss (ruby is not commonly installed) * don't double #include <math.h> * 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 babl with the vendor compiler Actual results: compilation fails in most cases, or else if babl 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 130363 [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 130364 [details] [review] config.h needs to be included at the top of every .c file in an autoconf project you missed a couple of files in your recent patch
Created attachment 130365 [details] [review] older aix and irix compilers choke on trailing commas in enum decls
Created attachment 130366 [details] [review] enum values must be less than INT_MAX (sign bit is illegal)
Created attachment 130367 [details] [review] some vendor C compilers choke on C++ comments
Created attachment 130368 [details] [review] some vendor compilers can't compile non-constant elements of compound struct initializers
Created attachment 130369 [details] [review] variadic macros are non-portable, use a glib like configure-time scheme falling back to variadic functions
Created attachment 130370 [details] [review] null-statements caused by trailing semicolons are non-portable
Created attachment 130371 [details] [review] support hpux use of shl_load/unload and dsos with .sl prefixes using gmodule might be cleaner than using a home-brew macro substitution this patch also converts to libtool module compilation to abstract away most of the details
Created attachment 130373 [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
Created attachment 130374 [details] [review] rewrite xml-insert.sh in portable bourne-shell also fixed the Makefile.am to call xml-insert.sh properly with an explicit shell, and to discard errors from which correctly
Created attachment 130375 [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 130376 [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 130377 [details] [review] changes to Makefile.am and configure.ac to support gnulib modules in the next patch
Created attachment 130378 [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 130379 [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 babl tarball. Most likely, you should fetch your own gnulib from git and: gnulib-tool --import extensions fpieee stdint
Created attachment 130380 [details] files generated by modern autotools gzip 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
Created attachment 131318 [details] revised quilt series file added a new patch put this file and all other attachments it names 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 131319 [details] [review] avoid the need for CPPFLAGS='-D__func__="unknown"' on some vendor compilers
(In reply to comment #9) > Created an attachment (id=130371) [edit] > support hpux use of shl_load/unload and dsos with .sl prefixes > > using gmodule might be cleaner than using a home-brew macro substitution > > this patch also converts to libtool module compilation to abstract away most of > the details > Everything works fine until I get to this patch, then I get errors like this: extensions/Makefile.am:14: `ext_LTLIBRARIES' is used but `extdir' is undefined Could you look into that before I continue please? I have commited all patches up until this patch.
(In reply to comment #20) > (In reply to comment #9) > > Created an attachment (id=130371) [edit] > > support hpux use of shl_load/unload and dsos with .sl prefixes > > > > using gmodule might be cleaner than using a home-brew macro substitution > > > > this patch also converts to libtool module compilation to abstract away most of > > the details > > > > Everything works fine until I get to this patch, then I get errors like this: > > extensions/Makefile.am:14: `ext_LTLIBRARIES' is used but `extdir' is undefined > > Could you look into that before I continue please? I have commited all patches > up until this patch. Sorry, I should've tested tested that, but the line is edited again later in the series for our bespoke tww.patch changeset, so I didn't notice the typo: s/ext_dir/extdir/ I'm reattaching all patch sets I've had to update due to changes in the tree after a fresh 'git pull'... the latest series file at comment #18 still lists the correct order to apply everything.
Created attachment 131655 [details] [review] support hpux use of shl load/unload and dsos with .sl suffixes
Created attachment 131656 [details] [review] don't try to pass gcc flags to vendor compilers
Created attachment 131657 [details] [review] avoid the need for CPPFLAGS='-D__func__="unknown"' on some vendor compilers
Created attachment 131658 [details] [review] changes to Makefile.am and configure.ac to support gnulib modules in the next patch
Created attachment 131659 [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 131660 [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 131661 [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 stdint
Created attachment 131662 [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 #25) > Created an attachment (id=131658) [edit] > changes to Makefile.am and configure.ac to support gnulib modules in the next > patch > Now everything goes smooth until this patch. If I apply this and build I get this error: checking whether build environment is sane... configure.ac:388: required file `lib/Makefile.in' not found Makefile.am:5: required directory ./lib does not exist Could you look into that please? Did you forgot to add lib/Makefile.am to the patch perhaps? Everything else before that is commited
(In reply to comment #30) > (In reply to comment #25) > > Created an attachment (id=131658) [edit] > > changes to Makefile.am and configure.ac to support gnulib modules in the next > > patch > > > > Now everything goes smooth until this patch. If I apply this and build I get > this error: > > checking whether build environment is sane... configure.ac:388: required file > `lib/Makefile.in' not found > Makefile.am:5: required directory ./lib does not exist > > Could you look into that please? Did you forgot to add lib/Makefile.am to the > patch perhaps? > > Everything else before that is commited 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 babl 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/babl--master--0 $ patch -p0 < patches/gnulib-prep.patch $ gnulib-tool --import extensions fpieee stdint 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!
The only thing I can see missing now is taking care of invoking gnulib-tool --update properly in autogen.sh and provide a helpful message why this fails, if it fails. Is there any de facto standard way of doing this?
It looks like Gary currently is busy doing other things so I am afraid we'll have to postpone this until after the 0.1.0 release. 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 before that.
Created attachment 166584 [details] [review] Patch to fetch gnulib from git To test : save patch in work directory and create a fresh git clone of babl in work directory: git clone git://git.gnome.org/babl cd babl patch -p1 <../gnulib.patch ./autogen.sh --force make
[Setting QA Contact to 'bugs at gegl.org' so people interested in following GEGL bug reports' changes can still follow if the assignee changes to a real person.]
There are still some patches in here, are they still necessary?
Why has the status been changed to "RESOLVED OBSOLETE" ?
Because it's been NEEDINFO for 4 months after asking if these patches were still necessary. The configure scripts have changed a lot since this bug was filed so it seems likely that the issues were addressed outside of the bug.