From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3216 Path: news.gmane.org!not-for-mail From: Igmar Palsenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Fri, 26 Apr 2013 08:11:07 +0200 Message-ID: <7DA8A203-CFF2-4559-AA2C-7CF38B5DD28E@palsenberg.com> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130425125121.GN20323@brightrain.aerifal.cx> <51795F26.6070805@eservices.virginia.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_3DCCC803-FB23-489A-945D-875B32FA4916" X-Trace: ger.gmane.org 1366956676 25608 80.91.229.3 (26 Apr 2013 06:11:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Apr 2013 06:11:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3220-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 26 08:11:20 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UVbsN-0003vp-OC for gllmg-musl@plane.gmane.org; Fri, 26 Apr 2013 08:11:19 +0200 Original-Received: (qmail 22036 invoked by uid 550); 26 Apr 2013 06:11:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22028 invoked from network); 26 Apr 2013 06:11:18 -0000 In-Reply-To: <51795F26.6070805@eservices.virginia.edu> X-Mailer: Apple Mail (2.1503) Xref: news.gmane.org gmane.linux.lib.musl.general:3216 Archived-At: --Apple-Mail=_3DCCC803-FB23-489A-945D-875B32FA4916 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 >>> incompatible licenses. The openssl library can't be used with a GNU >>> program unless there's a waiver for it because one of the clauses in = the >>> openssl license goes against the GNU license principles. The gnutls >> Not _used_ but _distributed_. The GPL does not restrict use >> whatsoever (and takes the position that it legally can't do so) so >> it's fine to use OpenSSL with GPL programs as long as you don't >> distribute the resulting binary. This is of course a problem for >> package maintainers/distributions, and distributing both openssl and >> the GNU program and a script to link them together might even be seen >> as an infringing activity. >=20 > What about explicitly loading the library at run-time using uselib(2) = in a plug-in like fashion? Is that also considered problematic from a = GNU perspective? I consider this a grey area. I personally don't thing it is considered a = problem, but there are a number of interesting (theoretical) scenario's = :=20 - You have a a.so that dynamically links GPL library b.so. Program C = loads a.so, and uses it's API, does it need to be GPL ? a.so can = alternatively also load d.so instead of b.so, which is BSD licensed. =20 Using / linking a GPL lib, and making the whole work as such GPL is a = clear violation. I personally avoid GPL libs where I can. >>> pkg-config has a nice replacement in pkgconf. (If a list is >>> created, might be helpful to list possible replacements already out >>> there.) Would like to see some of the pieces that are essential = parts of >>> the GNU build system/autotools replaced with some more efficient >>> [...] >>> of unnecessary work to port applications. Would rather see the = current >>> build systems already used (autotools, cmake, etc.) streamlined or = see drop >>> in replacements that are better designed. >> I seem to recall an effort somewhere to do exactly this, but I can't >> remember where I saw it.. >=20 > Here too, one option would be to have all of a library's options, = dependencies, and build steps represented in a real database (my = preference would be PostgreSql), and then have the actual build = script(s) generated using command-line utilities. This is something = that I have been doing in a rather miniature scale in a few = research-related projects, and found to be both effective and = expandable. Arguably, for all projects beyond a certain degree of = complexity, using a database to manage the build is the most feasible = path to follow (no need to name projects that demonstrate what happens = if you don't...), yet switching an existing build system to one that is = database-driven could become quite a challenge. I've done nice stuff with SQLIte. Make it also easy to transfer stuff to = a different system. Igmar --Apple-Mail=_3DCCC803-FB23-489A-945D-875B32FA4916 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 

incompatible licenses.  The openssl library can't be used with a GNU
program unless there's a waiver for it because one of the clauses in the
openssl license goes against the GNU license principles.  The gnutls

Not _used_ but _distributed_. The GPL does not restrict use
whatsoever (and takes the position that it legally can't do so) so
it's fine to use OpenSSL with GPL programs as long as you don't
distribute the resulting binary. This is of course a problem for
package maintainers/distributions, and distributing both openssl and
the GNU program and a script to link them together might even be seen
as an infringing activity.

What about explicitly loading the library at run-time using uselib(2) in a plug-in like fashion?  Is that also considered problematic from a GNU perspective?

I consider this a grey area. I personally don't thing it is considered a problem, but there are a number of interesting (theoretical) scenario's : 

- You have a a.so that dynamically links GPL library b.so. Program C loads a.so, and uses it's API, does it need to be GPL ? a.so can alternatively also load d.so instead of b.so, which is BSD licensed.
 
Using / linking a GPL lib, and making the whole work as such GPL is a clear violation. I personally avoid GPL libs where I can.

pkg-config has a nice replacement in pkgconf.  (If a list is
created, might be helpful to list possible replacements already out
there.)  Would like to see some of the pieces that are essential parts of
the GNU build system/autotools replaced with some more efficient
[...]
of unnecessary work to port applications.  Would rather see the current
build systems already used (autotools, cmake, etc.) streamlined or see drop
in replacements that are better designed.

I seem to recall an effort somewhere to do exactly this, but I can't
remember where I saw it..

Here too, one option would be to have all of a library's options, dependencies, and build steps represented in a real database (my preference would be PostgreSql), and then have the actual build script(s) generated using command-line utilities.  This is something that I have been doing in a rather miniature scale in a few research-related projects, and found to be both effective and expandable.  Arguably, for all projects beyond a certain degree of complexity, using a database to manage the build is the most feasible path to follow (no need to name projects that demonstrate what happens if you don't...), yet switching an existing build system to one that is database-driven could become quite a challenge.

I've done nice stuff with SQLIte. Make it also easy to transfer stuff to a different system.



Igmar

--Apple-Mail=_3DCCC803-FB23-489A-945D-875B32FA4916--