On Mon, 2012-02-13 at 14:55 +0100, Murray Cumming wrote:
On Wed, 2012-01-25 at 10:05 +0000, Patrick Ohly wrote:
> Is there a good reason for installing some libraries in a
> > sub-directory. Simplifying that might let use remove some hacks from
> > build files.
> I've wondered about that myself recently. In the end I settled on
> some hacks instead of moving the libs, mostly just because it was the
> smaller change.
> The original motivation was to avoid file clashes with other packages
> also providing libgdbus.so. That alone wasn't enough, because later
> symbols in that lib clashed with similarly named symbols in glib, so
> lib and all symbols were renamed.
> I don't think there still is any reason to install normal libraries in
> usr/lib/libsyncevolution. It should be used only for modules which get
> dlopened(). Want to provide a patch?
Sorry for the delay. Here it is. It's very simple.
... and it breaks "make -j install" ;-}
The libs are installed with:
/bin/bash ./libtool --mode=install /usr/bin/install -c src/syncevo/libsyncevolution.la
That's libsyncevolution.la before libgdbussyncevo.la. I guess it would
work if libgdbussyncevo.la came before libsyncevolution.la...
All in master now:
Author: Murray Cumming <murrayc(a)murrayc.com>
Date: Mon Feb 13 13:41:03 2012 +0100
Do not install libgdbussyncevo in a subdir
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Feb 15 14:03:54 2012 +0000
autotools: compile GDBus before libsyncevolution
libsyncevolution depends on GDBus, which therefore must be dealt
Mostly the dependencies take care of the right compilation order.
Installing the results is different, items of the same kind are
installed in the order in which they are added to their variables,
which in turn is defined by the order in which .am files are
That broke when making libgdbussyncevo a normal lib like
libsyncevolution (see next commit).
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.