Date: Wed, 21 Jul 2010 12:54:12 -0400 From: Dan Langille <dan@langille.org> To: Wesley Shields <wxs@FreeBSD.org> Cc: freebsd-ports@freebsd.org Subject: Re: sysytils/bacula-server link failures WITH_POSTGRESQL Message-ID: <4C472634.4010203@langille.org> In-Reply-To: <20100721165313.GA77932@atarininja.org> References: <4C442A0C.5050708@infracaninophile.co.uk> <20100721020738.GA21274@atarininja.org> <4C46E0BA.4070602@langille.org> <20100721122032.GA25553@atarininja.org> <4C46F182.4040704@langille.org> <20100721131625.GA26762@atarininja.org> <4C472249.2090500@langille.org> <20100721165313.GA77932@atarininja.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/21/2010 12:53 PM, Wesley Shields wrote:
> 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?
Go for it. :)
--
Dan Langille - http://langille.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C472634.4010203>