On 7/21/2010 2:41 PM, Kern Sibbald wrote:
> On Wednesday 21 July 2010 18:58:01 Dan Langille wrote:
>> 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).
>
> Well, there is the problem. LDFLAGS when used that way is designed to put the
> library in front of everything else, because it is a sort of special
> override.
>
> In principle, you should never need to specify LDFLAGS that way. Normally,
> Bacula will find where the PostgreSQL libraries are. If they are really in a
> different location, as is the case on say Solaris, then just specify them on
> the --with-postgresql=... option. If that doesn't work, we would have to see
> why because it works on all platforms that I know about.
>
>
>>
>>> 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.
>
> You shouldn't have to do that. If you do, then either FreeBSD is bizaare,
> which I doubt, or the Bacula ./configure is missing something.
I suppose that only leaves the option that FreeBSD is bizzare...
FreeBSD does install all third party libs into /usr/local/lib. That's
where they go. By design.
Thus, the settings of LDFLAGS is done by the ports build infrastructure
for all ports that use PostgreSQL. Which means we can't really change
the infrastructure for Bacula. But we can easily patch Bacula locally.
Not really a big deal for us. :)
>
> Kern
>
>>
>>>> __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
