[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] [patch] use autoconf2.5, config.guesss, #include

From: Glenn McGrath
Subject: Re: [GNUnet-developers] [patch] use autoconf2.5, config.guesss, #include <config.h>
Date: Tue, 14 May 2002 12:04:53 +1000

On Mon, 13 May 2002 19:58:00 -0500
"Blake Matheny" <address@hidden> wrote:

> > although i notice it links to openssl which has problems being linkled
> > to from GPL'ed binaries,
> Could you explain what you mean?
openssl uses a BSD type license with the advertising clause, the
advertising clause conflicts with the GPL

gnutls provide similar functionality to openssl and is under the GPL,
alternatively an exemption to the specific clause of the GPL could be
sought to allow linking to openssl (as the openssl link says).

> The storage format that is being used for GNUnet is really
> inconsequential. GNUnet is a _framework_ for a p2p system. The
> abstraction layer being coded (or being planned on) will allow a
> GNUnet user to use any storage backend that they like. Currently
> gdbm is just what GNUnet happens to default to using.

> We're currently not using the autoheader/config.h style of
> defines. Although we could, we currently aren't. This sounds like
> potentially something went wrong with the way you compiled GNUnet
> as I know that at least one developer is using Debian. Could you
> send the config.log to me off list? The AC_DEFINE_UNQUOTED is
> used to create a shell variable (-DLINUX=1 in the case of
> detecting Linux).
hmm, i cant reproduce it now, i dont know what i did wrong....
Previously when i tried running the server it gave an error running
"netstat -n -f inet -i" -f inst a valid option for my netstat (net-tools
1.60 netstat 1.42 (2001-04-15)), it works fine now.

> > As i was playing around with it i updated it to the autoconf2.5 style
> > i just ran autoscan to get most of the tests, not sure if
> > all those tests are actually needed.
> Unfortunately autoconf 2.1.3 (or around there) is still the
> default on many many systems. Since ~2.1 obviously is not
> forwards compatible (and ~2.5 is backwards compatible) it makes
> sense to just stick with mostly 2.1 syntax in order to support
> old and new autoconf versions.
I think it would be better to support either v2.13 or >= v2.5, and not try
and be compatable, i think trying to be compatble with both will cause
problems, as you mention below. As long as autoconf v2.5 can be installed
then i dont see a problem, but if 2.5 inst available on some systems then
i see your point.

> > I made it use configure.guess instead of uname to determien host type
> > as its more of a standard, i only tested it on my linux machine, not
> > sure if im testing for the right values for Sun and *BSD machines.
> Yeah, I was originally using that (I maintain the BSD ports) but
> I found that different systems were behaving differently based on
> autoconf version, and decided to stick with a generic method
> (just standard sh/autoconf valid syntax) to try to get this info.
> I'll play with your method and see if it's better then what we
> originally had, hopefully it is :-)
It should make it easier, or at least present the same problems that other
projects have :)

> > A patch against CVS that implements the above is attached.
> The patch breaks some things because of an existing config.h and the
> fact that /usr/lib/libgdbm.a is not necessarily a standard
> location for the library (could be /opt/gdbm/lib, /usr/local/lib,
> etc.). A better method for finding the gdbm lib would be to
> export your CPPFLAG and LDFLAG environment variables. The
> suggestions/patches are great, thanks. I'll look into the method
> you suggested for OS detection. Thanks.

I guess it would be nice to have a configure option for different database
formats, with ooptions to specify the library locations, like with ssl


reply via email to

[Prev in Thread] Current Thread [Next in Thread]