Hi James,
On 03/06/07, James Marsh <doctorja...@gmail.com> wrote:
Changing the link flags to use -static, -L and -l seems to fix things:
Index: configure.in
===================================================================
RCS file: /cvsroot/virtuoso/virtuoso-opensource/configure.in,v
retrieving revision 1.98
diff -u -r1.98 configure.in
--- configure.in 31 May 2007 12:28:17 -0000 1.98
+++ configure.in 3 Jun 2007 00:29:43 -0000
@@ -1254,7 +1254,8 @@
AM_CONDITIONAL(WITH_PERL, test "x$PERL" != "x" -a "x$with_perl" !=
"xno")
if test "x$PERL" != "x" -a "x$with_perl" != "xno" ; then
- PERL_LDFLAGS=`$PERL -MExtUtils::Embed -e ldopts`
+ PERL_LDFLAGS=`$PERL -MExtUtils::Embed -e ldopts | \
+ $PERL -pe 's/(\/\S+)\/(\S+?)\.a/-L$1 -static -l$2 -
shared/g'`
PERL_CFLAGS=`$PERL -MExtUtils::Embed -e ccopts`
fi
AC_SUBST(PERL_CFLAGS)
Forget that patch entirely. I seem to have inadvertently made it
just produce just a static version of the plugin.
Yes, i thought as much.
Looking into this a little more it seems the problem stems from the
included bin/libtool.macosx and the way it deals with building
static libraries. I have no use for static libraries, however on
the mac since the bin/libtool.macosx overrides the libtool that
gets generated based on the configuration options given to the
configure program, my "--disable-static" was ignored.
Hmm. i do not know if that will work everywhere. Sometimes we
specially build static libraries with shared objects for convenience.
Let me know if you have any more problems and i will see what i can
do about it.
Modifying bin/libtool.macosx so that build_old_libs=no causes the
build process to fail when building one of the convenience libraries.
The libtool.macosx has some patches that where not yet in either the
"official" libtool version or in the version Apple supplied
(glibtool) for building Universal binaries.
I will examine the latest 1.5.22 version of libtool to if they have
incorporated these fixes already, otherwise i will send my patches to
them. But because Apple does not ship any of these currently, i will
still need to ship a libtool.macosx version for now.
I will see if i can come up with a fix for the configure.in so you
can disable universal builds on Mac OS X, so you are free to use your
own versions of libtool and related flags.
What appears to be working better is this:
automake (GNU automake) 1.10
autoconf (GNU Autoconf) 2.61
libtoolize (GNU libtool) 1.5.22
I know, but since apple does not ship them i would like developers to
be able to build with what the system supplies, rather than forcing
everyone to upgrade their local tree.
Index: configure.in
===================================================================
RCS file: /cvsroot/virtuoso/virtuoso-opensource/configure.in,v
retrieving revision 1.98
diff -u -r1.98 configure.in
--- configure.in 31 May 2007 12:28:17 -0000 1.98
+++ configure.in 4 Jun 2007 10:11:51 -0000
@@ -256,15 +256,6 @@
######################################################################
####
AC_PROG_LIBTOOL
-#
-# Use our own libtool so we can perform Universal builds
-#
-case $host in
- *-darwin*)
- LIBTOOL='$(SHELL) $(top_srcdir)/bin/libtool.macosx'
- ;;
-esac
-
######################################################################
####
##
##
## Check various
headers ##
Another problem with my previous attempt at building the system:
4. If you supply --enable-imagemagick explicitly but then the test
program fails, the compile continues but without imagemagick
support being built. I would prefer to see it fail at this point as
presumably the user needs to specify the path as I've done above.
I will see what i can do.
Time to start playing with it!
Have fun and let us know how you are getting on.
Patrick
---
Patrick van Kleef
VOS maintainer
OpenLink Software
Universal Data Access & Data Integration Technology Providers
