On 7/21/2010 7:57 AM, Kern Sibbald wrote:
> On Wednesday 21 July 2010 13:35:15 Martin Simmons wrote:
>>>>>>> On Tue, 20 Jul 2010 15:36:24 -0400, Dan Langille said:
>>>
>>> FYI, I'm not yet sure if this is something we should solve here via
>>> config or if it's something I should fix in the FreeBSD port.
>>>
>>> I welcome opinions on it.
>>
>> Using --disable-libtool is the simplest solution -- no more pointless
>> shared libraries.
>
> This is certainly an option, but IMO it is not a good option because the cats
> library will be pulled into the Director, and at least one of the executables
> that are built with the storage daemon. The main bacula library will be
> compiled into *every* Bacula program. I could go on, but you should get the
> idea. That requires more disk space for the executables, and worse yet, it
> uses significantly more memory at runtime.
>
> In the future, it is quite likely we will not support building non-shared
> objects, principally, because we will probably be supporting the catalog only
> via shared objects in the next major release, so that a single Bacula binary
> can work with any catalog. I believe it would be better to find a suitable
> solution as soon as possible that permits you to use shared objects.
>
> If I could get a FreeBSD running in a VM, I would be happy to get more precise
> about resolving this, but I have tried about 5 times now, and I never
> succeeded, though I have Bacula running on Mac, many Linux machines, Solaris,
> Open Solaris, and many versions of Windows.
>
>>
>> Other possible fixes are to put the shared libraries somewhere private
>> rather than in /usr/local/lib (Bacula is the only thing that uses them) or
>> to change the Bacula makefiles so that the important built-in options like
>> -L../lib precede the configured options like -L/usr/local/lib.
>
> 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.
Yes, the FreeBSD ports system does indeed set LDFLAGS -L/usr/local/lib
and this is done for all ports/applications/programs that use PostgreSQL
(USE_PGSQL).
> Kern
>
> PS: I am not much inclined to try changing the order of libries on link lines,
> because there are so many places to do so, and it invariably breaks something
> on some platform. So if someone wants to submit such a patch, OK, but
> unfortunately you must have tested it on *every* possible platform :-(
Agreed. This is why I think we'll maintain this in the FreeBSD port
skeleton.
>
>>
>> __Martin
>>
>>> Short term, I will do something in the FreeBSD port.
>>>
>>> -------- Original Message --------
>>> Subject: [Bacula-users] Bacula 5.0.2 FreeBSD port fails to build during
>>> upgrade
>>> Date: Tue, 20 Jul 2010 12:20:21 -0400
>>> From: Paul Mather<p...@gromit.dlib.vt.edu>
>>> To: bacula-users<bacula-us...@lists.sourceforge.net>
>>>
>>> I'm running FreeBSD 8.1-PRERELEASE (RELENG_8). Recently, the
>>> sysutils/bacula-{client,server} ports were updated to 5.0.2.
>>> Unfortunately, when updating via portmaster, the bacula-client port
>>> updated successfully, but bacula-server did not. It fails to build:
>>>
>>> [[...]]
>>> Compiling ua_restore.c
>>> Compiling ua_run.c
>>> Compiling ua_select.c
>>> Compiling ua_server.c
>>> Compiling ua_status.c
>>> Compiling ua_tree.c
>>> Compiling ua_update.c
>>> Compiling vbackup.c
>>> Compiling verify.c
>>> 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
>>>
>>> Stop in /usr/ports/sysutils/bacula-server/work/bacula-5.0.2/src/dird.
>>>
>>>
>>> ====== Error in
>>> /usr/ports/sysutils/bacula-server/work/bacula-5.0.2/src/dird ======
>>>
>>>
>>> *** Error code 1
>>>
>>> Stop in /usr/ports/sysutils/bacula-server/work/bacula-5.0.2.
>>> *** Error code 1
>>>
>>> Stop in /usr/ports/sysutils/bacula-server.
>>> *** Error code 1
>>>
>>> Stop in /usr/ports/sysutils/bacula-server.
>>>
>>>
>>> It looks to me that the linking step above is wrong: it is picking up
>>> the old version of the library installed in /usr/local/lib by
>>> sysutils/bacula-server 5.0.0_1. It shouldn't be including
>>> "-L/usr/local/lib" in the invocation of libtool.
>>>
>>> Anyone who builds the port from scratch will not have a problem, but
>>> anyone updating via portmaster or portupgrade will run into the problems
>>> above.
>>>
>>> Cheers,
>>>
>>> Paul.
--
Dan Langille - http://langille.org/
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
