>>>>> On Tue, 22 Dec 2009 21:16:30 +0100, Kern Sibbald said: > > On Tuesday 22 December 2009 20:09:49 Phil Stracchino wrote: > > Martin Simmons wrote: > > >>>>>> On Tue, 22 Dec 2009 12:01:55 -0500, Phil Stracchino said: > > >> > > >> The relevant Makefile fragment is: > > >> > > >> libbac.la: Makefile $(LIBBAC_OBJS) > > >> @echo "Making $@ ..." > > >> $(LIBTOOL_LINK) $(CXX) $(DEFS) $(DEBUG) $(LDFLAGS) -o $@ > > >> $(LIBBAC_OBJS) -export-dynamic -rpath $(libdir) -version-info > > >> $(LIBBAC_LT_CURRENT):$(LIBBAC_LT_REVISION):$(LIBBAC_LT_AGE) $(WRAPLIBS) > > >> > > >> > > >> DEFAULT_OBJECT_TYPE is correctly defined to .lo in the Makefile. It > > >> appears that the line: > > >> > > >> LIBBAC_OBJS = $(LIBBAC_SRCS:.c=$(DEFAULT_OBJECT_TYPE)) > > >> > > >> is not actually working on OpenBSD as it is intended to. > > >> > > >> If I manually perform the expansion and edit the Makefile accordingly, > > >> the same problem occurs with LIBBACCFG_OBJS, then with LIBBACPY_OBJS. > > >> If I manually expand both of these as well, then also fix LIBOBJS in > > >> src/findlib/Makefile, the build completes and installs, and the client > > >> (at least) appears to work fine. > > > > > > Some BSD makes can't cope with nested expansions like that. Try using > > > GNU make. > > > > A quick test shows that this is indeed the problem. Unfortunately, the > > same testing also shows that gnu make cannot be used as a > > general-purpose replacement for BSD make on current OpenBSD systems, as > > BSD make contains ports-specific functionality without which nothing can > > be compiled using the BSD ports system. > > > > For a standalone build, this is a surmountable problem, as we can simply > > require that Bacula be compiled using gmake on OpenBSD. For people > > trying to build Bacula from ports, though, it's a real catch-22 - you're > > damned if you do, and damned if you don't. > > Thanks Martin. > > Our scripts should not be gnu make dependent (nor bash dependent). That > said, > if you don't have what I would call a "standard" make (such as found on > Solaris) then there will probably be some porting problems. > > We'll take a look at it to ensure we haven't slipped in some gnu dependency.
This particular case may be a bug in BSD make, because later versions of FreeBSD make do support it. __Martin ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
