You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Eike Rathke <oo...@erack.de> on 2011/08/28 19:12:12 UTC
[code] stuck at offapi on unxlngx6.pro
Hi,
First, I committed the configure --enable-copyleft thingy Mathias and
I hacked together about a month ago. So if you now pull from the repo
and configure, these copylefts are disabled by default.
Second, I committed missing files I encountered during the build up to
offapi, that are
graphite/graphite-2.3.1.patch
readlicense_oo/html/THIRDPARTYLICENSEREADME.html
Third, I committed some small changes gcc 4.6.1 complained about that
broke the build.
Fourth, now I'm stuck at module offapi where idlc bails out with completely
senseless messages:
Entering /build/aooo/main/offapi/com/sun/star/sdb
Compiling: Forms.idl
../../../../com/sun/star/ucb/Content.idl(296) : Illegal syntax following service member declaration: syntax error, unexpected IDL_IDENTIFIER
../../../../com/sun/star/ucb/Content.idl(311) : Statement can not be parsed: property
../../../../com/sun/star/ucb/Content.idl(313) : Statement can not be parsed: syntax error, unexpected '-', expecting ';'
and 100s more after that. Content.idl line 296 and following are in the
middle of comments, apparently idlc attempts to parse those as idl
definitions. Currently I have no idea why.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Eike Rathke <oo...@erack.de>.
Hi,
On Sunday, 2011-08-28 23:14:37 +0200, Eike Rathke wrote:
> header guards removed (hmm.. I could try that)
Crazy idea, but IT WORKS!
Juergen will certainly scratch his head while analyzing that quirk ;-)
Committed.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Mathias Bauer <Ma...@gmx.net>.
On 28.08.2011 23:14, Eike Rathke wrote:
> Hi Michael,
>
> On Sunday, 2011-08-28 22:30:44 +0200, Michael Stahl wrote:
>
>>> Compiling: Forms.idl
>>> ../../../../com/sun/star/ucb/Content.idl(296) : Illegal syntax following service member declaration: syntax error, unexpected IDL_IDENTIFIER
>> i have had the exact same problem trying to build OOO340m1 on my Fedora
>> box. for now i've just worked around the problem by removing the big
>> 100s-line comment in Content.idl, then invoking "build" in offapi, then
>> putting the comment back.
>
> Well, that's an attempt worth to be tried :-)
>
>> strangely it only happens when building files
>> that include Content.idl, not with Content.idl itself.
>
> Indeed.
>
>> guess it's some bug in idlc, or perhaps a compiler bug (gcc 4.6.0 here).
>
> gcc 4.6.1 here, but building LibreOffice no problem, though compiler
> options are probably different, Content.idl is nearly identical except
> header guards removed (hmm.. I could try that) and corrected typos in
> the documentation comments (does idlc now bail out on those if file was
> included? ;-)
I have gcc 4.5.2 on Ubuntu and the problem doesn't appear. So at least a
compiler bug is possible.
Regards,
Mathias
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Eike Rathke <oo...@erack.de>.
Hi Michael,
On Sunday, 2011-08-28 22:30:44 +0200, Michael Stahl wrote:
> > Compiling: Forms.idl
> > ../../../../com/sun/star/ucb/Content.idl(296) : Illegal syntax following service member declaration: syntax error, unexpected IDL_IDENTIFIER
> i have had the exact same problem trying to build OOO340m1 on my Fedora
> box. for now i've just worked around the problem by removing the big
> 100s-line comment in Content.idl, then invoking "build" in offapi, then
> putting the comment back.
Well, that's an attempt worth to be tried :-)
> strangely it only happens when building files
> that include Content.idl, not with Content.idl itself.
Indeed.
> guess it's some bug in idlc, or perhaps a compiler bug (gcc 4.6.0 here).
gcc 4.6.1 here, but building LibreOffice no problem, though compiler
options are probably different, Content.idl is nearly identical except
header guards removed (hmm.. I could try that) and corrected typos in
the documentation comments (does idlc now bail out on those if file was
included? ;-)
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Michael Stahl <ms...@openoffice.org>.
On 28.08.2011 19:12, Eike Rathke wrote:
> Fourth, now I'm stuck at module offapi where idlc bails out with completely
> senseless messages:
>
> Entering /build/aooo/main/offapi/com/sun/star/sdb
>
> Compiling: Forms.idl
> ../../../../com/sun/star/ucb/Content.idl(296) : Illegal syntax following service member declaration: syntax error, unexpected IDL_IDENTIFIER
> ../../../../com/sun/star/ucb/Content.idl(311) : Statement can not be parsed: property
> ../../../../com/sun/star/ucb/Content.idl(313) : Statement can not be parsed: syntax error, unexpected '-', expecting ';'
>
> and 100s more after that. Content.idl line 296 and following are in the
> middle of comments, apparently idlc attempts to parse those as idl
> definitions. Currently I have no idea why.
i have had the exact same problem trying to build OOO340m1 on my Fedora
box. for now i've just worked around the problem by removing the big
100s-line comment in Content.idl, then invoking "build" in offapi, then
putting the comment back. strangely it only happens when building files
that include Content.idl, not with Content.idl itself.
guess it's some bug in idlc, or perhaps a compiler bug (gcc 4.6.0 here).
regards,
michael
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Mathias Bauer <Ma...@gmx.net>.
Am 29.08.2011 18:31, schrieb Stephan Bergmann:
> By the way, the source code at idlc/source/preproc appears to be
> copied from LCC code (see
> <http://en.wikipedia.org/wiki/LCC_(compiler)>) and then erroneously
> decorated with the OOo license header. This needs to be addressed.
> Similarly, the code at soltools/cpp appears to be a second copy of
> that code, with the same memcpy error, but at least without the
> erroneous OOo license headers.
I have added this to the list at
http://wiki.services.openoffice.org/wiki/ApacheMigration#TODO
Regards,
Mathias
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Stephan Bergmann <st...@googlemail.com>.
On Aug 29, 2011, at 6:55 PM, Jürgen Schmidt wrote:
> On Mon, Aug 29, 2011 at 6:31 PM, Stephan Bergmann <
> stephan.bergmann.secondary@googlemail.com> wrote:
>>
>> By the way, the source code at idlc/source/preproc appears to be copied
>> from LCC code (see <http://en.wikipedia.org/wiki/LCC_(compiler)>) and then
>> erroneously decorated with the OOo license header. This needs to be
>> addressed. Similarly, the code at soltools/cpp appears to be a second copy
>> of that code, with the same memcpy error, but at least without the erroneous
>> OOo license headers.
> With the cleanup of this license headers we can try to remove the code in
> one place and reuse it.
…if its OK to have the code included in AOOo at all, license-wise.
-Stephan
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Mathias Bauer <Ma...@gmx.net>.
Am 29.08.2011 19:00, schrieb Michael Stahl:
> On 29.08.2011 18:55, Jürgen Schmidt wrote:
>> On Mon, Aug 29, 2011 at 6:31 PM, Stephan Bergmann <
>> stephan.bergmann.secondary@googlemail.com> wrote:
>
>>> By the way, the source code at idlc/source/preproc appears to be copied
>>> from LCC code (see <http://en.wikipedia.org/wiki/LCC_(compiler)>) and then
>>> erroneously decorated with the OOo license header. This needs to be
>>> addressed. Similarly, the code at soltools/cpp appears to be a second copy
>>> of that code, with the same memcpy error, but at least without the erroneous
>>> OOo license headers.
>>>
>>
>> oh the good old preproc code from Horst (i am sure some of you know who
>> Horst is -> it's an insider joke from the early days and before OOo was
>> born).
>>
>> With the cleanup of this license headers we can try to remove the code in
>> one place and reuse it.
>
> any reason why we build our own preprocessors and don't use the C
> toolchain preprocessor that is already required to build OOo?
Ask Horst.
But before that you have to GetHorstByName. :-)
SCNR,
Mathias
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Michael Stahl <ms...@openoffice.org>.
On 30.08.2011 08:47, Stephan Bergmann wrote:
> On Aug 29, 2011, at 9:26 PM, Pedro F. Giffuni wrote:
>>> any reason why we build our own preprocessors and don't use the C
>>> toolchain preprocessor that is already required to build OOo?
>>>
>>
>> This is an important question. If we need another preprocessor
>> there are options(1), but we need to now why.
>
> At least for idlc, I think the best solution would be to get rid of a
> C preprocessor completely. Even if de-facto (if not also de-jure)
> .idl files have always been passed through a C preprocessor, so in
> theory could make use of all the C preprocessor's features, this has
> practically always only been used for plain #include <…> or #include
> "…" stuff (plus internal and external header guards, #ifndef
> XXX/#define XXX/.../#endif and #ifndef XXX/#include "YYY"/#endif), I
> think.
>
> So, it should be possible---without breaking backwards compatibility
> in practice---to change idlc so that it ignores all #… lines except
> for #include lines, which it then handles via a more efficient
> mechanism than textual inclusion.
that's the question i never dared to ask ;)
i hate cpp: it is an automated copy-paste mechanism to do things for
which a real programming language provides a module system.
let's get rid of it where possible.
then we can also remove the ugly external header guards clutter.
> Would still have to have a look at soltools/cpp, though...
>
> -Stephan
regards,
michael
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Eike Rathke <oo...@erack.de>.
Hi Stephan,
On Tuesday, 2011-08-30 17:48:53 +0200, Stephan Bergmann wrote:
> >> Would still have to have a look at soltools/cpp, though...
> > I think that was used only in the old mkdepend, maybe some other build
> > tool as well.
>
> Grepping through the source code, it is used in exactly one place,
> namely in the $(PAR)/%.par rule in solenv/inc/pstrules.mk. Can
> hopefully be replaced with preprocess-only calls to the various
> platform's C or C++ compilers (the used command line arguments are
> quasi-standard -D and -I and LCC-cpp specific -+ to support C++ (or
> C99) comments and -P to "print no line information").
Should be fine.
I should had taken a look at mkdepend's source again.. didn't remember
that after almost two decades.
Btw, that mkdepend isn't used at all.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Stephan Bergmann <st...@googlemail.com>.
On Aug 30, 2011, at 3:13 PM, Eike Rathke wrote:
> On Tuesday, 2011-08-30 08:47:18 +0200, Stephan Bergmann wrote:
>> Would still have to have a look at soltools/cpp, though...
> I think that was used only in the old mkdepend, maybe some other build
> tool as well.
Grepping through the source code, it is used in exactly one place, namely in the $(PAR)/%.par rule in solenv/inc/pstrules.mk. Can hopefully be replaced with preprocess-only calls to the various platform's C or C++ compilers (the used command line arguments are quasi-standard -D and -I and LCC-cpp specific -+ to support C++ (or C99) comments and -P to "print no line information").
-Stephan
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Eike Rathke <oo...@erack.de>.
Hi Stephan,
On Tuesday, 2011-08-30 08:47:18 +0200, Stephan Bergmann wrote:
> Would still have to have a look at soltools/cpp, though...
I think that was used only in the old mkdepend, maybe some other build
tool as well.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Stephan Bergmann <st...@googlemail.com>.
On 30.08.2011, at 14:40, "Pedro F. Giffuni" <gi...@tutopia.com> wrote:
> --- On Tue, 8/30/11, Stephan Bergmann wrote:
>
> ...
>>>
>>> This is an important question. If we need another
>>> preprocessor there are options(1), but we need to now
>>> why.
>>
>> At least for idlc, I think the best solution would be to
>> get rid of a C preprocessor completely. Even if
>> de-facto (if not also de-jure) .idl files have always been
>> passed through a C preprocessor, so in theory could make use
>> of all the C preprocessor's features, this has practically
>> always only been used for plain #include <…> or
>> #include "…" stuff (plus internal and external header
>> guards, #ifndef XXX/#define XXX/.../#endif and #ifndef
>> XXX/#include "YYY"/#endif), I think.
>>
>
> OK, thanks for explaining. The idea of just ripping of code
> that we don't like is rather scary but i this case I guess
> it could work at the expense of some robustness.
>
>> So, it should be possible---without breaking backwards
>> compatibility in practice---to change idlc so that it
>> ignores all #… lines except for #include lines, which it
>> then handles via a more efficient mechanism than textual
>> inclusion.
>>
>
> This sounds like a job for embedded ucpp under the
> "lexer" mode.[1] It's pretty small and very manageable,
> plus we need a lexer anyways. Sorry my C-fu is not good :(.
>>
We already have a lexer for .idl, implemented with flex. It's more like, upon an #include directive, idlc need not literally include the given file's content but could rather obtain the necessary information about the entity defined in the included file from the types.rdb database, more or less.
-Stephan
Re: [code] stuck at offapi on unxlngx6.pro
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
--- On Tue, 8/30/11, Stephan Bergmann wrote:
...
> >
> > This is an important question. If we need another
> > preprocessor there are options(1), but we need to now
> > why.
>
> At least for idlc, I think the best solution would be to
> get rid of a C preprocessor completely. Even if
> de-facto (if not also de-jure) .idl files have always been
> passed through a C preprocessor, so in theory could make use
> of all the C preprocessor's features, this has practically
> always only been used for plain #include <…> or
> #include "…" stuff (plus internal and external header
> guards, #ifndef XXX/#define XXX/.../#endif and #ifndef
> XXX/#include "YYY"/#endif), I think.
>
OK, thanks for explaining. The idea of just ripping of code
that we don't like is rather scary but i this case I guess
it could work at the expense of some robustness.
> So, it should be possible---without breaking backwards
> compatibility in practice---to change idlc so that it
> ignores all #… lines except for #include lines, which it
> then handles via a more efficient mechanism than textual
> inclusion.
>
This sounds like a job for embedded ucpp under the
"lexer" mode.[1] It's pretty small and very manageable,
plus we need a lexer anyways. Sorry my C-fu is not good :(.
> Would still have to have a look at soltools/cpp, though...
>
This is probably easier to replace since it's a standalone
tool.
In addition to mcpp, the Portable C compiler[2] also
includes a preprocessor that should be comparable to the
one in lcc.
hth,
Pedro.
ps. Repeated here for convenience:
[1] http://code.google.com/p/ucpp/
[2] http://pcc.ludd.ltu.se/
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Stephan Bergmann <st...@googlemail.com>.
On Aug 29, 2011, at 9:26 PM, Pedro F. Giffuni wrote:
>> any reason why we build our own preprocessors and don't use
>> the C toolchain preprocessor that is already required to
>> build OOo?
>>
>
> This is an important question. If we need another
> preprocessor there are options(1), but we need to now
> why.
At least for idlc, I think the best solution would be to get rid of a C preprocessor completely. Even if de-facto (if not also de-jure) .idl files have always been passed through a C preprocessor, so in theory could make use of all the C preprocessor's features, this has practically always only been used for plain #include <…> or #include "…" stuff (plus internal and external header guards, #ifndef XXX/#define XXX/.../#endif and #ifndef XXX/#include "YYY"/#endif), I think.
So, it should be possible---without breaking backwards compatibility in practice---to change idlc so that it ignores all #… lines except for #include lines, which it then handles via a more efficient mechanism than textual inclusion.
Would still have to have a look at soltools/cpp, though...
-Stephan
soltools/cpp replacement options (was Re: [code] stuck at offapi on unxlngx6.pro)
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
Hi again;
FWIW, This one looks like an interesting option as it
is made to be embeddable too:
http://code.google.com/p/ucpp/
"ucpp can be compiled as a stand-alone program, or linked to some other code; in the latter case, ucpp will output tokens, one at a time, on demand, as an integrated lexer."
cheers,
Pedro.
--- On Mon, 8/29/11, Pedro F. Giffuni wrote:
...
>
> This is an important question. If we need another
> preprocessor there are options(1), but we need to now
> why.
>
> cheers,
>
> Pedro.
>
> (1) http://mcpp.sourceforge.net/
>
Re: [code] stuck at offapi on unxlngx6.pro
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
--- On Mon, 8/29/11, Michael Stahl wrote:
...
> >
> > With the cleanup of this license headers we can try to
> > remove the code in one place and reuse it.
>
LCC is not copyleft and in our particular use it may be
OK, but some provisions could be problematic:
https://github.com/drh/lcc/blob/master/CPYRIGHT
> any reason why we build our own preprocessors and don't use
> the C toolchain preprocessor that is already required to
> build OOo?
>
This is an important question. If we need another
preprocessor there are options(1), but we need to now
why.
cheers,
Pedro.
(1) http://mcpp.sourceforge.net/
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Michael Stahl <ms...@openoffice.org>.
On 29.08.2011 18:55, Jürgen Schmidt wrote:
> On Mon, Aug 29, 2011 at 6:31 PM, Stephan Bergmann <
> stephan.bergmann.secondary@googlemail.com> wrote:
>> By the way, the source code at idlc/source/preproc appears to be copied
>> from LCC code (see <http://en.wikipedia.org/wiki/LCC_(compiler)>) and then
>> erroneously decorated with the OOo license header. This needs to be
>> addressed. Similarly, the code at soltools/cpp appears to be a second copy
>> of that code, with the same memcpy error, but at least without the erroneous
>> OOo license headers.
>>
>
> oh the good old preproc code from Horst (i am sure some of you know who
> Horst is -> it's an insider joke from the early days and before OOo was
> born).
>
> With the cleanup of this license headers we can try to remove the code in
> one place and reuse it.
any reason why we build our own preprocessors and don't use the C
toolchain preprocessor that is already required to build OOo?
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On Mon, Aug 29, 2011 at 6:31 PM, Stephan Bergmann <
stephan.bergmann.secondary@googlemail.com> wrote:
> On Aug 28, 2011, at 7:12 PM, Eike Rathke wrote:
> > Fourth, now I'm stuck at module offapi where idlc bails out with
> completely
> > senseless messages:
> >
> > Entering /build/aooo/main/offapi/com/sun/star/sdb
> >
> > Compiling: Forms.idl
> > ../../../../com/sun/star/ucb/Content.idl(296) : Illegal syntax following
> service member declaration: syntax error, unexpected IDL_IDENTIFIER
> > ../../../../com/sun/star/ucb/Content.idl(311) : Statement can not be
> parsed: property
> > ../../../../com/sun/star/ucb/Content.idl(313) : Statement can not be
> parsed: syntax error, unexpected '-', expecting ';'
> >
> > and 100s more after that. Content.idl line 296 and following are in the
> > middle of comments, apparently idlc attempts to parse those as idl
> > definitions. Currently I have no idea why.
>
> A memcpy that should rather be a memmove at <
> http://hg.services.openoffice.org/OOO340/file/c904c1944462/idlc/source/preproc/tokens.c#l480>,
> see also <
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=03657f66600c64b33443c30952054c11d82f9c7d
> >.
>
> By the way, the source code at idlc/source/preproc appears to be copied
> from LCC code (see <http://en.wikipedia.org/wiki/LCC_(compiler)>) and then
> erroneously decorated with the OOo license header. This needs to be
> addressed. Similarly, the code at soltools/cpp appears to be a second copy
> of that code, with the same memcpy error, but at least without the erroneous
> OOo license headers.
>
oh the good old preproc code from Horst (i am sure some of you know who
Horst is -> it's an insider joke from the early days and before OOo was
born).
With the cleanup of this license headers we can try to remove the code in
one place and reuse it.
Juergen
>
> -Stephan
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Stephan Bergmann <st...@googlemail.com>.
On Aug 28, 2011, at 7:12 PM, Eike Rathke wrote:
> Fourth, now I'm stuck at module offapi where idlc bails out with completely
> senseless messages:
>
> Entering /build/aooo/main/offapi/com/sun/star/sdb
>
> Compiling: Forms.idl
> ../../../../com/sun/star/ucb/Content.idl(296) : Illegal syntax following service member declaration: syntax error, unexpected IDL_IDENTIFIER
> ../../../../com/sun/star/ucb/Content.idl(311) : Statement can not be parsed: property
> ../../../../com/sun/star/ucb/Content.idl(313) : Statement can not be parsed: syntax error, unexpected '-', expecting ';'
>
> and 100s more after that. Content.idl line 296 and following are in the
> middle of comments, apparently idlc attempts to parse those as idl
> definitions. Currently I have no idea why.
A memcpy that should rather be a memmove at <http://hg.services.openoffice.org/OOO340/file/c904c1944462/idlc/source/preproc/tokens.c#l480>, see also <http://cgit.freedesktop.org/libreoffice/core/commit/?id=03657f66600c64b33443c30952054c11d82f9c7d>.
By the way, the source code at idlc/source/preproc appears to be copied from LCC code (see <http://en.wikipedia.org/wiki/LCC_(compiler)>) and then erroneously decorated with the OOo license header. This needs to be addressed. Similarly, the code at soltools/cpp appears to be a second copy of that code, with the same memcpy error, but at least without the erroneous OOo license headers.
-Stephan
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Hi Eike,
i will take a look on it tomorrow. I took a break last week and have to
catch up some mails and more ...
Regards
Juergen
On Sun, Aug 28, 2011 at 7:36 PM, Eike Rathke <oo...@erack.de> wrote:
> Hi,
>
> Btw, my configure is
>
> PKG_CONFIG=/usr/bin/pkg-config ./configure \
> --with-use-shell=bash \
> --disable-strip-solver \
> --without-fonts \
> --without-ppds \
> --with-system-stdlibs
>
> PKG_CONFIG=... was neeed because configure complained about pkg-config
> version not being sufficient or not found, but that's nonsense, it's in
> the standard $PATH, maybe of an unexpected version.
>
> Usually I had a large list of --with-system-... or just
> --with-system-libs and --with-system-headers, but did not include that
> to build as much as possible from the repository.
>
> Eike
>
> --
> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Eike Rathke <oo...@erack.de>.
Hi Mathias,
On Sunday, 2011-08-28 21:22:25 +0200, Mathias Bauer wrote:
> My configure is
>
> PKG_CONFIG=/usr/bin/pkg-config ./configure \
> --without-junit \
> --disable-librsvg \
> --with-external-tar=/home/mathias/ext_sources
>
> I used the first parameter because I don't want to do the extended
> tests now, the second is an artefact we still need to fix (this
> switch should be the default).
That's even misnamed in ./configure --help which says
--enable-librsvg Determines whether to use librsvg library on
platforms where librsvg is available.
[...]
The intention of defaulting this flag to yes is to
indicate this fact to the build maintainer)
So if that's always on it really should be mentioned as
--disable-librsvg instead.
> The third one is may local external-repodir.
Of course I have that as well but omitted to mention it.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Mathias Bauer <Ma...@gmx.net>.
On 28.08.2011 19:36, Eike Rathke wrote:
> Hi,
>
> Btw, my configure is
>
> PKG_CONFIG=/usr/bin/pkg-config ./configure \
> --with-use-shell=bash \
> --disable-strip-solver \
> --without-fonts \
> --without-ppds \
> --with-system-stdlibs
>
> PKG_CONFIG=... was neeed because configure complained about pkg-config
> version not being sufficient or not found, but that's nonsense, it's in
> the standard $PATH, maybe of an unexpected version.
>
> Usually I had a large list of --with-system-... or just
> --with-system-libs and --with-system-headers, but did not include that
> to build as much as possible from the repository.
>
> Eike
>
I can't reproduce your problem in offapi. My configure is
PKG_CONFIG=/usr/bin/pkg-config ./configure \
--without-junit \
--disable-librsvg \
--with-external-tar=/home/mathias/ext_sources
I used the first parameter because I don't want to do the extended tests
now, the second is an artefact we still need to fix (this switch should
be the default). The third one is may local external-repodir.
Regards,
Mathias
Re: [code] stuck at offapi on unxlngx6.pro
Posted by Eike Rathke <oo...@erack.de>.
Hi,
Btw, my configure is
PKG_CONFIG=/usr/bin/pkg-config ./configure \
--with-use-shell=bash \
--disable-strip-solver \
--without-fonts \
--without-ppds \
--with-system-stdlibs
PKG_CONFIG=... was neeed because configure complained about pkg-config
version not being sufficient or not found, but that's nonsense, it's in
the standard $PATH, maybe of an unexpected version.
Usually I had a large list of --with-system-... or just
--with-system-libs and --with-system-headers, but did not include that
to build as much as possible from the repository.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD