headers
Mike Boone | 4 Aug 2009 22:30
Favicon
Gravatar

1.0.14 Core Build Error

I am trying this on Mac OS X 10.5.7:

svn co svn://svn.xapian.org/xapian/tags/1.0.14 xapian-1.0.14
cd xapian-1.0.14
./bootstrap
cd xapian-core/
./configure --disable-documentation --enable-maintainer-mode
make

This runs for a while and then stops with this error:

 g++ -DHAVE_CONFIG_H -I. -I./common -I./include -Wall -W
-Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align
-Wno-long-long -Wformat-security -fno-gnu-keywords
-Woverloaded-virtual -Wundef -Wshadow -Wstrict-null-sentinel
-fvisibility=hidden -Werror -g -O2 -MT api/omquery.lo -MD -MP -MF
api/.deps/omquery.Tpo -c api/omquery.cc  -fno-common -DPIC -o
api/.libs/omquery.o
cc1plus: warnings being treated as errors
api/omquery.cc: In constructor
‘Xapian::Query::Query(Xapian::Query::op, Xapian::Query)’:
api/omquery.cc:128: warning: ‘__base_ctor ’ is deprecated (declared at
api/omquery.cc:118)
make[2]: *** [api/omquery.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Any ideas?

Thanks,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Olly Betts | 5 Aug 2009 04:31
Favicon
Gravatar

Re: 1.0.14 Core Build Error

On Tue, Aug 04, 2009 at 04:30:42PM -0400, Mike Boone wrote:
>  g++ -DHAVE_CONFIG_H -I. -I./common -I./include -Wall -W
> -Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align
> -Wno-long-long -Wformat-security -fno-gnu-keywords
> -Woverloaded-virtual -Wundef -Wshadow -Wstrict-null-sentinel
> -fvisibility=hidden -Werror -g -O2 -MT api/omquery.lo -MD -MP -MF
> api/.deps/omquery.Tpo -c api/omquery.cc  -fno-common -DPIC -o
> api/.libs/omquery.o
> cc1plus: warnings being treated as errors
> api/omquery.cc: In constructor
> ?Xapian::Query::Query(Xapian::Query::op, Xapian::Query)?:
> api/omquery.cc:128: warning: ?__base_ctor ? is deprecated (declared at
> api/omquery.cc:118)
> make[2]: *** [api/omquery.lo] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> Any ideas?

Well, "__base_ctor" is nothing to do with us, so this sounds like a
toolchain issue.  Google turns up a few hits for "__base_ctor is
deprecated", but I didn't see anything explaining it.

If you can find a fix, I can try to slot it into configure or the
makefiles.

You can work around it by just building the problematic file without
-Werror:

make CXXFLAGS=-Wno-error api/omquery.lo
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Aylett | 5 Aug 2009 13:34

Re: 1.0.14 Core Build Error

On Wed, Aug 05, 2009 at 03:31:42AM +0100, Olly Betts wrote:

> Well, "__base_ctor" is nothing to do with us, so this sounds like a
> toolchain issue.  Google turns up a few hits for "__base_ctor is
> deprecated", but I didn't see anything explaining it.

I can reproduce this error with both XCode 3.1.2 and 3.1.3.

> make CXXFLAGS=-Wno-error api/omquery.lo

This passes fine. No other compilation units have this problem.

> If you can find a fix, I can try to slot it into configure or the
> makefiles.

This is happening (and only happening here) because this version/patch
of gcc emits deprecated constructors as warnings in a different way
from deprecated functions or methods. This is the only deprecated
constructor right now.

Quite why this is suddenly biting (given I was able to build this not
that long ago, and nothing obvious has changed around this code or the
deprecation system) I don't know. Possibly a knock-on effect of more
recent autotools?

To fix this, we could conditionally redefine #define
XAPIAN_DEPRECATED(D) (D) within api/query.h, although that's not very
pleasant. Given it only happens on this platform (that we know of)
I don't feel that a solution involving a different macro for
deprecated constructors is wise.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Boone | 5 Aug 2009 15:17
Favicon
Gravatar

Re: 1.0.14 Core Build Error

On Wed, Aug 5, 2009 at 7:34 AM, James Aylett<james-xapian <at> tartarus.org> wrote:
>> make CXXFLAGS=-Wno-error api/omquery.lo
>
> This passes fine. No other compilation units have this problem.

Thanks guys, this works fine for me also. I'm on XCode 3.1.2.

Mike.
Permalink | Reply | 0 comments |
headers
James Aylett | 7 Aug 2009 14:06

Licensing

Afternoon all. I was discussing the current licensing of Xapian and
how it influences the way we work with someone at another OSS project
recently, and although the upshot is likely to be that they'll amend
their license (it's a corporate foundation, and GPL compatibility is
something they desire for precisely this reason), it did prompt me to
think about how we're tracking where we are on the license issue.

As per <http://trac.xapian.org/wiki/FAQ/CommercialLicence>, we have a
clear idea of who owns what (modulo some uncertainty around
Brightstation copyright ownership). Certainly for easily-contactable
entities, we know who contributed to which file, and indeed could
figure out ownership down to the change level.

It strikes me that, given many of the current contributors to Xapian
are agreed in principle in a bright and shiny future of LGPL
licensing, having everyone expressly license their contributions under
the LGPL might be a helpful thing. It wouldn't get us any closer to
changing the license (which still requires replacing or removing all
code that cannot be relicensed), but it will prevent us from getting
any further away from that possibility, which might happen if a
contributor falls out of contact with the project for whatever reason.

What we do not want is to move forward to a position where we should
be able to change to LGPL, and then cannot get explicit permission
from a contributor for whatever reason; I've been in this situation
before, and it's more than slightly frustrating. Since currently the
only license grant that occurs on contributions to Xapian is GPL, this
needs an explicit statement by each contributor.

To get the ball rolling: all code and modifications I have contributed
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Boulton | 11 Aug 2009 16:23
Gravatar

Re: Licensing

2009/8/7 James Aylett <james-xapian <at> tartarus.org>
To get the ball rolling: all code and modifications I have contributed
to Xapian may be licensed under either the GPL (as stands) or LGPL (if
this is practical for the code in question). Similarly, both the GPL
and LGPL may be used for my future contributions.

I discussed this this morning with the other directors of Lemur Consulting, and we're happy to change the license for the contributions we have made.  We actually think that LGPL may be too restrictive, so it would be useful to keep the option of using the MIT or Apache2 licenses, too.  The MIT license is about as unrestrictive as you can get (other than Public Domain, or attempts to replicate Public Domain with a license), and Apache2 is similar to MIT but with a "mutual annihilation" patent clause.  Therefore, Lemur says:

All code and modifications that Lemur has contributed to Xapian may be licensed under either the GPL version 2 or later (as stands), or the LGPL version 2.1 or later, or the Apache2 license, or the MIT license, where this is practical for the code in question (ie, except where Lemur does not hold the copyright on the code submitted, and is therefore unable to change the license).  Similarly, any of these licenses may be used for future Lemur modifications, unless explicitly stated to the contrary.

For the text of these licenses, see (respectively)

http://www.opensource.org/licenses/gpl-2.0.php
http://www.opensource.org/licenses/lgpl-2.1.php
http://www.opensource.org/licenses/apache2.0.php
http://www.opensource.org/licenses/mit-license.php

--
Richard
_______________________________________________
Xapian-devel mailing list
Xapian-devel <at> lists.xapian.org
http://lists.xapian.org/mailman/listinfo/xapian-devel
Permalink | Reply | 0 comments |

Gmane