Fix LDFLAGS for cross-compilation

[ffontaine]

Remove "-L$(libdir)" from LDFLAGS of boinc libraries in Makefile.am of
api, lib, sched and zlib directories to be able to cross-compile boinc.

Indeed, libdir is not equal to the path where BOINC will be installed
but to exec_prefix/lib. The full installation path is
$(DESTDIR)/$(libdir).

To cross-compile boinc, exec_prefix will be set to the target path (for
example: /usr) and DESTDIR will be set (during make install) to the
staging or target directory on the host (for example /home/xxx/target).
The issue of adding -L$(libdir) is that it is not allowed by the
compiler, the error "unsafe header/library path used in
cross-compilation: '-L/usr/lib'" will be raised.

As a result, remove -L$(libdir)" from LDFLAGS, the default library
search paths are sufficient for "standard" compilation or can be updated
manually by passing the additional search path to LDFLAGS during the
configure call for cross-compilation.

Signed-off-by: Fabrice Fontaine fontaine.fabrice@gmail.com

[AenBleidd]

@ffontaine Could you please fix this? Thanks

[ChristianBeer]

The error in travis CI was caused by a broken master branch because of 91784e9 which was fixed in 9edb755 and this pull request was processed when the fix was not yet available. I restarted the CI build with the latest master and now it is green.

[AenBleidd]

@ChristianBeer, Than you Best regards, Vitalii

[ChristianBeer]

I would like to see #1793 and #1790 merged before this and then rerun the tests on this PR just to make sure our own cross compile can handle this. I can merge those two PRs tomorrow.

[ChristianBeer]

@ffontaine How are you cross-compiling? Can you give some commands that I can try locally?

[ffontaine]

I'm cross-compiling using buildroot (https://buildroot.org).
The goal of this PR was to provide a official patch to integrate boinc to buildroot packages.
To test the patch, I used the qemu_arm_versatile_defconfig default configuration. I was waiting the merge of this PR to finalize my patch but I can push it to buildroot mailing list by the end of the day and give the link to this patch if you want to test it.
As soon as you'll get the patch, you'll have to apply it to your git clone of https://git.buildroot.net/buildroot and then:

$ cd buildroot/
$ make qemu_arm_versatile_defconfig
select boinc in "Networking applications"
$ make
run the command specified in board/qemu/arm-versatile/readme.txt

[ffontaine]

boinc patch for buildroot is here: https://patchwork.ozlabs.org/patch/735295/.
I have currently disabled the manager and server as libnotify is not available yet on buildroot. Moreover, buildroot targets embedded devices so I'm mostly interested to the client and library parts of boinc.

[ffontaine]

I updated the patch to also remove "-rpath $(libdir)" following the review of my buildroot patch by Thomas.

[ChristianBeer]

From the patch discussion:

+BOINC_VERSION = 26198
+BOINC_SITE = $(call github,BOINC,boinc,vboxwrapper/$(BOINC_VERSION))

What is this vboxwrapper/ version?

All github releases since July 2016 starts with vboxwrapper. I suppose
that's becaue the "standard" way of installing boinc is through virtual
box. vboxwrapper is the name of the boinc package installed inside virtual
box. This package can contain the client, the server, the manager, ...

@ffontaine your assumption is wrong. The vboxwrapper tags are only for the vboxwrapper tool located in samples/vboxwrapper. It has little to do with how BOINC is installed and vboxwrapper is an application that is used by projects to run scientific applications inside virtual box containers. If you want to grab client/manager releases the tag format is client_release/7.6/7.6.33 which can only be used to build the Client and Manager not the Server parts. The Server currently has no versioning.
So you would need to use something like this:

BOINC_MAJMIN = 7.6
BOINC_POINT = 33
BOINC_SITE = $(call github,BOINC,boinc,client_release/$(BOINC_MAJMIN)/$(BOINC_MAJMIN).$(BOINC_POINT))

Back to topic: I couldn't find a definitive reason why -L$(libdir) -rpath where added. It seems they are not needed at least for our test builds. If nobody else objects I'm going to invoke my 14 day rule and merge this in 8 days.

Regarding the license in COPYING: this should be cleared up shortly as I think this was a copy and paste error.

[ffontaine]

Thanks for this clarification, I will update my patch accordingly. However, how can I know what is the latest version of client_release? 7.4.52 is the latest client_release version referenced in https://github.com/BOINC/boinc/releases. Should I check https://boinc.berkeley.edu/download_all.php?

[AenBleidd]

@ffontaine You can find all relevent verions here: http://boinc.berkeley.edu/download_all.php?xml=1

[ChristianBeer]

Regarding the license issue in case you are not following boinc_dev this is what @nicolas17 found out:

This is because the LGPLv3 is written as supplemental clauses on top
of GPLv3. The text of the LGPLv3 alone is not a complete license.
"This version of the GNU Lesser General Public License incorporates
the terms and conditions of version 3 of the GNU General Public
License, supplemented by the additional permissions listed below."

And from the howto https://www.gnu.org/licenses/gpl-howto.html:
"If you are releasing your program under the LGPL, you should also
include the text version of the LGPL, usually in a file called
COPYING.LESSER. Please note that, since the LGPL is a set of
additional permissions on top of the GPL, it's important to include
both licenses so users have all the materials they need to understand
their rights."

[ChristianBeer]

Thanks for your contribution.