Re: [gthumb-list] Another patch (#2) to make 2.14.3 build on FreeBSD

["Ronald F. Guilmette" <rfg tristatelogic com>]

In message <4F97BAB6 7010601 libero it>, 
Paolo Bacchilega <paolo bacchilega libero it> wrote:

> Il 25/04/2012 07:03, Ronald F. Guilmette ha scritto:
> > I was unable to have the link step for gthumb 2.14.3 complete successfully
> > on FreeBSD, at least until I applied the following patch.
> >
> > Really, I am surprised that _anybody_ was able to successfully link gthumb
> > 2.14.3 on _any_ platform, because it seems rather evident to me that nowhere
> > in the gthumb/Makefile (or in the corresponding Makefile.in file or in the
> > corresponding Makefile.am file) was there ever any proper -l option to instr
> uct
> > the linker to drag in various routines from /usr/local/lib/libgconf-2.a whic
> h
> > are clearly referenced in the gconf-utils.c source file (e.g. the function
> > `gconf_is_initialized', referenced on line 77 of gconf-utils.c, but also man
> y
> > many other such references in that same file to routines defined within the
> > /usr/local/lib/libgconf-2.a library).
> >
> > diff -rc2 ./gthumb/Makefile.am ./gthumb/Makefile.am
> > *** ./gthumb/Makefile.am     2011-11-03 13:36:36.000000000 -0700
> > --- ./gthumb/Makefile.am     2012-04-24 21:50:33.000000000 -0700
> > ***************
> > *** 274,277 ****
> > --- 274,278 ----
> >      $(LIBSOUP_LIBS)                                 \
> >      $(LIBCHAMPLAIN_LIBS)                            \
> > +    -lgconf-2                                       \
> >      $(NULL)
> >
> >
> >
> > After appling the above patch, a whole huge slew of link-time error messages
> > went away, and the build process was then able to progress further.
> >
> >
> > How did 2.14.3 ever build for _anybody_, ever, without any explicit -lgconf-
> 2
> > option anywhere in any of the relevant Makefiles??
> >
> > It is very puzzling.
>
> the GConf library should be included in GTHUMB_LIBS, I have no idea why 
> this is not the case for you.


I apologize, but due to a small oversight on my part I did not see this
response until now.

Anyway, I looked into this problem some more and now it seems that it was
perhaps caused by a misunderstanding on my end and also by a small
problem/issue relating to the following relatively recent change:

===========================================================================
commit bc1ec9fe0ebc8f28ab12053c90ef51e1ceca4660
Author: xcsnake free fr <xcsnake free fr>
Date:   2012-01-28

    added zlib in PKG_CHECK_MODULES for GTHUMB

M       configure.ac

===========================================================================

The misunderstanding on my part was that I incorrectly assumed that anything
I set as the value of GTHUMB_LIBS in my environment would be additive to
whatever configure came up with.  However I now see that this is used only
to completely override whatever configure comes up with.

Anyway, regarding the addition of zlib to PKG_CHECK_MODULES for GTHUMB, that
change is problematic when the build environment is FreeBSD.  On FreeBSD
there are quite a number of .pc files that may get built and installed
in the directory /usr/local/libdata/pkgconfig (specifically ones for
various FreeBSD "ports" of various free software libraries) but there is
no zlib.pc file among them, apparently for the simple reason that the
files /usr/lib/libz.{a,so} are a part of the "base" FreeBSD system.

In my opinion, this problem is worth some re-jiggering of the configure.ac
file, i.e. in order to properly adapt gthumb to this particular and unique
property of FreeBSD, however I, for one, am not that adept at writing these
autoconfig .ac files, so I'll have to leave that up to someone else.

For now, I implemented a simple local work-around on my own system.  I simply
created a zlib.pc file by hand myself and stuck it into the FreeBSD
/usr/local/libdata/pkgconfig directory.  So far, this work-around seems to
work.  With it in place I was able to build gthumb 2.14.3 to completion
and without the patch shown above.