Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 21/07/2010 03:07, Wesley Shields wrote: 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 -- WXS I applied the patch on a couple of VMs I'm using as a dev system, and it's been chugging away happily all morning. Looks good. Cheers Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
Il 07/19/10 12:33, Matthew Seaman ha scritto: Would it be sensible to make either WITH_POSTGRESQL or WITH_MYSQL the default options setting for this port rather than WITH_SQLITE? In my experience for backing up any reasonably sized system, you do need a fully competent RDBMS for the bacula catalog. Also, please, another request: out of the box, there are no options for the query command (/usr/local/share/bacula/query.sql is empty); the manual suggests examples/sample-query.sql to start with, but this is not installed. Could it be? bye Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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?
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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. ;)
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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-develm=127971346713102w=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
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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-develm=127971346713102w=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.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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-develm=127971346713102w=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/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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-develm=127971346713102w=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?
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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-develm=127971346713102w=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/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 7/19/2010 7:22 AM, 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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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.
Dan, what do you think about this patch? If you approve I will commit it
when I am back from traveling (tonight/tomorrow morning). I just want to
reply to this to let people know that I'll take care of this with
Matthew and Dan.
The above issue was just raised on the Bacula Users mailing list:
http://marc.info/?l=bacula-usersm=127964325714652w=2
I approve. You go for it. :)
Would it be sensible to make either WITH_POSTGRESQL or WITH_MYSQL the
default options setting for this port rather than WITH_SQLITE? In my
experience for backing up any reasonably sized system, you do need a
fully competent RDBMS for the bacula catalog.
I'll leave that up to Dan.
I like the WITH_POSTGRESQL. I am blatantly biased in this regard.
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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.
Dan, what do you think about this patch? If you approve I will commit it
when I am back from traveling (tonight/tomorrow morning). I just want to
reply to this to let people know that I'll take care of this with
Matthew and Dan.
Would it be sensible to make either WITH_POSTGRESQL or WITH_MYSQL the
default options setting for this port rather than WITH_SQLITE? In my
experience for backing up any reasonably sized system, you do need a
fully competent RDBMS for the bacula catalog.
I'll leave that up to Dan.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 7/19/2010 6:33 AM, 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:
That's not very nice, considering PostgreSQL is my preferred database.
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.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +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.
Would it be sensible to make either WITH_POSTGRESQL or WITH_MYSQL the
default options setting for this port rather than WITH_SQLITE? In my
experience for backing up any reasonably sized system, you do need a
fully competent RDBMS for the bacula catalog.
WITH_POSTGRESQL I think. :)
Looking at the diff:
http://cvsweb.unixathome.org/cgi-bin/cvsweb.cgi/ports/sysutils/bacula-server/Makefile.diff?r1=1.124;r2=1.125;cvsroot=freebsd
That seems to have been dropped.
I won't be able to get to this immediately to create a patch but if
someone else wishes to, that's great.
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
Il 07/19/10 12:33, Matthew Seaman ha scritto: 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: This happened to me too... Workaround is to deinstall bacula-server, then compile and install the new version. bye av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
