sysytils/bacula-server link failures WITH_POSTGRESQL

[Dan Langille]

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'?

-- 
Dan Langille - http://langille.org/