On Sun, 2014-01-19 at 16:56 +0000, Graham Cobb wrote:
One small problem: the syncevolution build finishes by creating the
README, which requires executing the version of syncevolution that has
just been built. In my case, that doesn't work.
I built libsynthesis, installed it in /usr/local and then told
syncevolution configure to look there (using
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/). I did
NOT put /usr/local into LD_LIBRARY_PATH. That is mainly because my
syncevoution testing involves using a script which sets up several
important environment variables, including LD_LIBRARY_PATH (and, in
fact, I do my testing on a different machine). Anyway, the compilation
all worked but the syncevolution that is built cannot be run. Which is
fine by me, but not fine for this final stage of the build.
It would be nice if one of several things was possible:
1) The README building script worked out how to set LD_LIBRARY_PATH
(pkg-config worked out where the library was, after all).
I disagree here slightly. I think pkg-config is meant to find installed,
usable versions of the libraries. When installing a lib into a
non-standard local (non-standard = not search by default) then whoever
installs it there needs to ensure that it works. This means setting
PKG_CONFIG_PATH and, if the .pc file doesn't contain an rpath setting
for the lib, also LD_LIBRARY_PATH.
Having to second-guess how the lib was installed IMHO makes using it too
complex and shouldn't be in the user of the lib.
2) I could tell configure to statically link libsynthesis.
If libsynthesis was configured with "--disable-dynamic --enable-static",
SyncEvolution will use the static library. However, because it gets
linked into a dynamic library, one also has to use "-DPIC -fpic" as
CFLAGS and CXXFLAGS when configuring libsynthesis.
3) I could tell configure that the built image won't run and the
step was dropped.
4) The perl script which creates the README handled syncevolution not
running and put some default text in instead.
The building of the README is already more tolerant if doing
cross-compilation. In that case, the compiled executable might not work
on the build machine. It is tried to run it, but when it fails, a
fallback text about sync and source properties gets inserted into the
I did not want that tolerant behavior as default because then it would
be very easy to not notice the incomplete doc when building a release
and something broke (like not having LD_LIBRARY_PATH set).
I'm fine with adding a configure option. Should the more tolerant
behavior be the default or the stricter, current approach?
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.