From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3206 Path: news.gmane.org!not-for-mail From: Zvi Gilboa Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Thu, 25 Apr 2013 12:51:50 -0400 Message-ID: <51795F26.6070805@eservices.virginia.edu> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130425125121.GN20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090006070203030905070501" X-Trace: ger.gmane.org 1366908723 22217 80.91.229.3 (25 Apr 2013 16:52:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Apr 2013 16:52:03 +0000 (UTC) To: Original-X-From: musl-return-3210-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 25 18:52:08 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 1UVPOt-0005Vp-EO for gllmg-musl@plane.gmane.org; Thu, 25 Apr 2013 18:52:03 +0200 Original-Received: (qmail 21851 invoked by uid 550); 25 Apr 2013 16:52:02 -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 21843 invoked from network); 25 Apr 2013 16:52:02 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 In-Reply-To: <20130425125121.GN20323@brightrain.aerifal.cx> X-Originating-IP: [172.25.136.26] Xref: news.gmane.org gmane.linux.lib.musl.general:3206 Archived-At: --------------090006070203030905070501 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 04/25/2013 08:51 AM, Rich Felker wrote: > On Thu, Apr 25, 2013 at 07:44:39AM -0400, LM wrote: >> 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? >> 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. --------------090006070203030905070501 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 04/25/2013 08:51 AM, Rich Felker wrote:
On Thu, Apr 25, 2013 at 07:44:39AM -0400, LM wrote:
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?

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.


--------------090006070203030905070501--