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.
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.
------------------------------------------------------------------------------
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
