sysytils/bacula-server link failures WITH_POSTGRESQL

[Wesley Shields]

On Wed, Jul 21, 2010 at 12:37:29PM -0400, Dan Langille wrote:
> On 7/21/2010 9:16 AM, Wesley Shields wrote:
> > On Wed, Jul 21, 2010 at 09:09:22AM -0400, Dan Langille wrote:
> >> On 7/21/2010 8:20 AM, Wesley Shields wrote:
> >>> On Wed, Jul 21, 2010 at 07:57:46AM -0400, Dan Langille wrote:
> >>>> On 7/20/2010 10:07 PM, Wesley Shields wrote:
> >>>>> On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
> >>>>>>
> >>>>>> Dear port maintainer,
> >>>>>>
> >>>>>> Since version 5.0.2 was committed over the weekend, if you select
> >>>>>> WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
> >>>>>> fails to link:
> >>>>>>
> >>>>>> Linking bacula-dir ...
> >>>>>> /usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
> >>>>>> --tag=CXX --mode=link /usr/bin/c++  -L/usr/local/lib -L../lib -L../cats
> >>>>>> -L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
> >>>>>> backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
> >>>>>> getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
> >>>>>> next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
> >>>>>> scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
> >>>>>> ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
> >>>>>> ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
> >>>>>> verify.o  -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
> >>>>>> -L/usr/local/lib -lpq -lcrypt -lpthread  -lintl  -lwrap
> >>>>>> /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
> >>>>>> -Wl,/usr/local/lib -lssl -lcrypto
> >>>>>> /usr/local/lib/libbacsql.so: undefined reference to
> >>>>>> `rwl_writelock(s_rwlock_tag*)'
> >>>>>> *** Error code 1
> >>>>>>
> >>>>>> This seems to be autoconf / libtool flail: removing -L/usr/local/lib
> >>>>>> from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
> >>>>>> ${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
> >>>>>> linking to work correctly.
> >>>>>>
> >>>>>> # diff -u Makefile{~,}
> >>>>>> --- Makefile~    2010-07-19 10:33:43.000000000 +0100
> >>>>>> +++ Makefile    2010-07-19 10:40:07.000000000 +0100
> >>>>>> @@ -84,7 +84,7 @@
> >>>>>>      CFLAGS = -O2 -pipe -fno-strict-aliasing
> >>>>>>
> >>>>>>      CPPFLAGS = -I/usr/local/include
> >>>>>> -LDFLAGS =  -L/usr/local/lib
> >>>>>> +LDFLAGS =
> >>>>>>      TTOOL_LDFLAGS =
> >>>>>>      #DEFS = -DHAVE_CONFIG_H
> >>>>>>      LIBS = -lpthread  -lintl
> >>>>>>
> >>>>>> This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
> >>>>>> of those result in LDFLAGS being set in referenced Makefiles.
> >>>>>
> >>>>> After talking to Dan briefly this is a known problem with upgrades. It
> >>>>> looks like the build process looks in /usr/local/lib instead of using
> >>>>> the libraries it just built when it does the linking. It finds the old
> >>>>> library, which is missing the newer symbols, and fails to link. By
> >>>>> pushing /usr/local/lib after the rest of the -L arguments in the
> >>>>> necessary places this appears to build properly now. I'd appreciate
> >>>>> further testing of the patch. Your initial patch is only applicable
> >>>>> after the Makefiles have been generated by configure.
> >>>>>
> >>>>> Dan, my initial testing indicates that this allows the port to build.
> >>>>> I'd appreciate another set of eyeballs on it though. Please let me know
> >>>>> if you would like me to commit this patch or not.
> >>>>>
> >>>>> http://people.freebsd.org/~wxs/bacula-unbreak.diff
> >>>>
> >>>> I'd like to pass this URL on to the bacula-devel mailing list please.
> >>>> That OK with you?
> >>>
> >>> Sure, with the caveat that it could be the totally wrong fix for this
> >>> problem. ;)
> >>
> >> I will consider that soon... However, this recent part is interesting:
> >>
> >>     http://marc.info/?l=bacula-devel&m=127971346713102&w=2
> >>
> >> "In general, as far as I can tell, this occurs because you have
> >> explicitly added /usr/local/lib to an environment variable that you feed
> >> to the ./configure script.  This should not really be necessary, because
> >> if you let the configure figure out the libraries itself  (aside from
> >> the ones like postgres or mysql that you specify on a ./configure
> >> option), it works on all other systems, and never experience this problem."
> >>
> >> Do you think perhaps this is the culprit?
> >>
> >> # make -V LDFLAGS
> >>    -L/usr/local/lib
> >
> > Yes, but that is set in bsd.database.mk I believe.
> 
> Recent posts to the thread pasted above indicate that is the cause of 
> the problem.   Perhaps bsd.database.mk is 'the root of all evil'?

Yes, but it is needed so that we can link with the necessary libraries.

I took a quick glance through the thread and it doesn't look like there
are major objections to this patch, just that they don't want to include
it upstream, which is understandable. This fix can be maintained by the
ports community until it is no longer needed (if ever). I'd like to
commit this patch so we can get upgrades working for people who use
postgres. Do you have any issues with me committing this?

-- WXS