My make of up-to-date LyX-CVS ends with:
In file included from ../../../../boost/boost/regex/config.hpp:54,
from cpp_regex_traits.cpp:22:
../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in
type `long'
gmake[4]: *** [cpp_regex_traits.lo] Error 1
On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote:
> My make of up-to-date LyX-CVS ends with:
Me too (well, something similar) gcc 3.5.0cvs
Didn't spot the problem immediately
john
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote:
>
>> My make of up-to-date LyX-CVS ends with:
>
| Me too (well, something similar) gcc 3.5.0cvs
I don't get either.
g++ --version
g++ (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
g++ --version
g
Lars Gullik Bjønnes wrote:
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote:
My make of up-to-date LyX-CVS ends with:
| Me too (well, something similar) gcc 3.5.0cvs
I don't get either.
I need this, to successfully compile CVS:
Index: boost/boost/
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> John Levon <[EMAIL PROTECTED]> writes:
>> | On Mon, May 31, 2004 at 11:00:13AM +0900, Rob Lahaye wrote:
>>
My make of up-to-date LyX-CVS ends with:
>>>
>> | Me too (well, something similar) gcc 3.5.0cvs
>> I don't get eithe
-g -O
-fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF
.deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o
In file included from ../../../../boost/boost/regex/config.hpp:54,
from cpp_regex_traits.cpp:22:
../../../../boost/boost/cstdint.hpp:121: e
config.hpp:54,
| from cpp_regex_traits.cpp:22:
| ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in
| type `long'
| gmake[4]: *** [cpp_regex_traits.lo] Error 1
>
| -
>
| FreeBSD 4.10-STABLE i386
| GCC 3.3.4 20040505 (prerelease) [
boost/boost/regex/config.hpp:54,
| from cpp_regex_traits.cpp:22:
| ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in
| type `long'
| gmake[4]: *** [cpp_regex_traits.lo] Error 1
| -
| FreeBSD 4.10-STABLE i386
| GCC 3.3.4 20040505 (prere
Rob Lahaye <[EMAIL PROTECTED]> writes:
>> Ok, it must be FreeBSD that is the "problem"
>> Is uintmax_t a macro? Or uint32_t?
>> Has on FreeBSD changed recently?
>> (upgraded libc perhaps?)
>> What is uintmax_t/uint32_t typdeffed/defined as in
>
| This is what I get:
| $ grep -n uintmax_t /usr/in
On Wed, Jun 02, 2004 at 12:56:24PM +0200, Lars Gullik Bj?nnes wrote:
> Ok, it must be FreeBSD that is the "problem"
No, I have recently started seeing a very similar problem on Linux.
/usr/local/gcc-cvs/bin/g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src
-I../../../../boost -I/usr/X11R6/include
"
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jun 02, 2004 at 12:56:24PM +0200, Lars Gullik Bj?nnes wrote:
>
>> Ok, it must be FreeBSD that is the "problem"
>
| No, I have recently started seeing a very similar problem on Linux.
Completely different you mean...
>
| /usr/local/gcc-cvs/bin/g++
On Wed, Jun 02, 2004 at 03:37:52PM +0200, Lars Gullik Bj?nnes wrote:
> Sure it did. Or do you have a goblin in your box?
> (you installed gcc 3.5 right? But I don't see these errors with 3.5...)
I previously compiled CVS lyx fine with the same GCC version. A cvs
update then caused it to fail.
>
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jun 02, 2004 at 03:37:52PM +0200, Lars Gullik Bj?nnes wrote:
>
>> Sure it did. Or do you have a goblin in your box?
>> (you installed gcc 3.5 right? But I don't see these errors with 3.5...)
>
| I previously compiled CVS lyx fine with the same GCC v
On Wed, Jun 02, 2004 at 04:12:14PM +0200, Lars Gullik Bj?nnes wrote:
> of gcc or lyx?
lyx
> nothing in lyx/boost changed... automake/autoconf differences?
I haven't changed versions of that.
> Your is some syntax problem, the one on FreeBSD is redefinition of a
> type.
Either way, I can't do
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jun 02, 2004 at 04:12:14PM +0200, Lars Gullik Bj?nnes wrote:
>
>> of gcc or lyx?
>
| lyx
>
>> nothing in lyx/boost changed... automake/autoconf differences?
>
| I haven't changed versions of that.
>
>> Your is some syntax problem, the one on FreeBSD
On Wed, Jun 02, 2004 at 05:19:50PM +0200, Lars Gullik Bj?nnes wrote:
> How can I help when you clam up on the info I need!
What info do you want?
john
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jun 02, 2004 at 05:19:50PM +0200, Lars Gullik Bj?nnes wrote:
>
>> How can I help when you clam up on the info I need!
>
| What info do you want?
Tell me everything.
But something _must_ have change I can't belive that it is lyx (sure
it could be .
On Wed, Jun 02, 2004 at 06:35:15PM +0200, Lars Gullik Bj?nnes wrote:
> But something _must_ have change I can't belive that it is lyx (sure
> it could be ...)
Nothing's changed, honest. No RPMs have been updated. GCC 3.5 is the one
that previously compiled lyx successfully. LyX is CVS up to date.
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jun 02, 2004 at 06:35:15PM +0200, Lars Gullik Bj?nnes wrote:
>
>> But something _must_ have change I can't belive that it is lyx (sure
>> it could be ...)
>
| Nothing's changed, honest. No RPMs have been updated. GCC 3.5 is the one
| that previously
On Wed, Jun 02, 2004 at 06:48:07PM +0200, Lars Gullik Bj?nnes wrote:
> How updated are your 3.5?
Very. The problem is that the gettext.m4 changes are doing:
typedef int ptrdiff_t
into config.h. However, the check is going wrong because of course
ptrdiff_t is defined fine on my system, so you e
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jun 02, 2004 at 06:48:07PM +0200, Lars Gullik Bj?nnes wrote:
>
>> How updated are your 3.5?
>
| Very. The problem is that the gettext.m4 changes are doing:
>
| typedef int ptrdiff_t
>
| into config.h. However, the check is going wrong because of cou
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I do this:
>
| #!/bin/bash
>
| export PATH=/opt/gcc-head/bin:$PATH
| export LD_LIBRARY_PATH=/opt/gcc-head/lib
>
| exec bash -i
>
| Does that make a difference? (change to fit of course)
>
| Do you have any clues why configure thinks your ptrdiff_t
On Wed, Jun 02, 2004 at 08:46:51PM +0200, Lars Gullik Bj?nnes wrote:
> I can only find ptrdiff_t in linux/types.h and in
> /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/stddef.h
> (which leads me to suspect your way of calling the compiler...)
>
> It seems that STDC_HEADERS is undefined with y
John Levon <[EMAIL PROTECTED]> writes:
| On Wed, Jun 02, 2004 at 08:46:51PM +0200, Lars Gullik Bj?nnes wrote:
>
>> I can only find ptrdiff_t in linux/types.h and in
>> /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/stddef.h
>> (which leads me to suspect your way of calling the compiler...)
>>
>
On Thu, Jun 03, 2004 at 12:31:01AM +0200, Lars Gullik Bj?nnes wrote:
> Ha! I win!
I gracefully concede (this one).
But only because I appear to have burnt my nose.
john
st/cstdint.hpp:118: error: syntax error before `;' token
../../../../boost/boost/cstdint.hpp:121: error: syntax error before `unsigned'
gmake[4]: *** [cpp_regex_traits.lo] Error 1
[.and many more error lines, related to above error]
What else can I do, to clarify this problem?
Regards,
Rob.
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> Rob Lahaye <[EMAIL PROTECTED]> writes:
>>
Ok, it must be FreeBSD that is the "problem"
Is uintmax_t a macro? Or uint32_t?
Has on FreeBSD changed recently?
(upgraded libc perhaps?)
What is uintmax_t/uint32_t
Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:
| I have these results:
| 1) Everything compiles like a charm, when I comment out in
| boost/boost/cstdint.hpp this line
| // typedef uint64_t uintmax_t;
Rob Lahaye <[EMAIL PROTECTED]> writes:
| All I can find, is this in /usr/include/machine/ansi.h:
>
|#ifdef __GNUC__
|typedef int __attribute__((__mode__(__DI__)))__int64_t;
|typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t;
|#else
|/* LONGLONG */
|
| Does that ring a bell?
Unfortunately not.
We should perhaps try to find a reduced testcase that also fails.
---
#include
int main()
{
}
---
Is that enouthg to trigger it?
put the file in a lyx topdir and compile with g++ -W -Wall -Iboost -c
-o test.o test.C
$ cd
$ cat test.C
#include
int ma
Rob Lahaye <[EMAIL PROTECTED]> writes:
>>>
>> | Does that ring a bell?
>> Unfortunately not.
>> We should perhaps try to find a reduced testcase that also fails.
>> ---
>> #include
>> int main() {
>> }
>> ---
>> Is that enouthg to trigger it?
>> put the file in a lyx topdir and compile with g++ -
-DBOOST_USER_CONFIG=" -g -O
-fno-exceptions -W -Wall -c cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF
.deps/cpp_regex_traits.TPlo -o cpp_regex_traits.o
In file included from ../../../../boost/boost/regex/config.hpp:54,
from cpp_regex_traits.cpp:22:
../../../../boost/boost
_CONFIG_H -I. -I. -I../../../../src -I../../../../boost
-I/opt/include -I/usr/local/include -I/usr/X11R6/include
"-DBOOST_USER_CONFIG=" -g -O -fno-exceptions -W -Wall -c
cpp_regex_traits.cpp -MT cpp_regex_traits.lo -MD -MP -MF .deps/cpp_regex_traits.TPlo
-o cpp_regex_traits.o
| In file
Lars Gullik Bjønnes:
So it is some combination of headers that cause this.
Please try this:
$ cat test.C ; g++ -W -Wall -Iboost -c -o test.o test.C
# include
# include
# include
# include
# include
# include
# include
# include
# include
# include
# include
# include
# incl
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Again, no problem. What else can I do?
I feel a bit lost now...
--
Lgb
Lars Gullik Bjønnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>
> | Again, no problem. What else can I do?
>
> I feel a bit lost now...
Rob, I take it that this fails to compile:
#include
int main() { return 0; }
Compile with a suitably modified
$ g++ -I/boost -o trial trial.C
--
Ang
Angus Leeming:
Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Again, no problem. What else can I do?
I feel a bit lost now...
Rob, I take it that this fails to compile:
Nah, also no problem:
$ cat test.C ; g++33 -Iboost -o test.o test.C
#include
int main() { return 0; }
$
And
from boost/boost/regex/config.hpp:54,
from test.C:1:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long'
-
*HOWEVER*:
when I remove -DBOOST_USER_CONFIG="" from this line,
it compiles without error!!!
Does that r
Rob Lahaye wrote:
>> Rob, I take it that this fails to compile:
>
> Nah, also no problem:
>
> $ cat test.C ; g++33 -Iboost -o test.o test.C
> #include
> int main() { return 0; }
So what happens if you #include *all* the system
headers of cpp_regex_traits.cpp
#include
#include
#include
#in
t/libs/regex/src -Isrc -Iboost \
> -I/usr/local/include -I/usr/X11R6/include
> -DBOOST_USER_CONFIG="" \ -fno-exceptions -W -Wall -c
> -o test.lo test.C
> In file included from boost/boost/regex/config.hpp:54,
> from test.C:1:
> boost/boost/cs
-Iboost -I/usr/local/include \
-I/usr/X11R6/include -DBOOST_USER_CONFIG="" -fno-exceptions -W -Wall \
-c -o test.lo test.C
In file included from boost/boost/regex/config.hpp:54,
from test.C:1:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in
Rob Lahaye wrote:
So what now happens if you reduce your test case to the more minimal
#include
int main { return 0; }
where you compile with your 'lyx-style' command line invocation of g++?
Incidentally, Lars, if we pass -DBOOST_USER_CONFIG="", why
do we add it to also?
> #define BOOST_USER
Angus Leeming <[EMAIL PROTECTED]> writes:
| Rob Lahaye wrote:
>
| So what now happens if you reduce your test case to the more minimal
>
| #include
| int main { return 0; }
>
| where you compile with your 'lyx-style' command line invocation of g++?
>
| Incidentally, Lars, if we pass -DBOOST_USER_
boost/libs/regex/src -Isrc -Iboost \
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG="" \
-fno-exceptions -W -Wall -c -o test.lo test.C
In file included from test.C:1:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long'
Once again: remov
Rob Lahaye wrote:
> Once again: removing -DBOOST_USER_CONFIG="" from the
> compile line above, solves the problem.
> Does that bring us any closer?
Sure. Something in is messing up the (quite small)
You should try and isolate the #define that is screwing things up.
As a preliminary guess,
Angus Leeming wrote:
Rob Lahaye wrote:
Once again: removing -DBOOST_USER_CONFIG="" from the
compile line above, solves the problem.
Does that bring us any closer?
Sure. Something in is messing up the (quite small)
You should try and isolate the #define that is screwing things up.
As a prel
Rob Lahaye wrote:
> Hmmm, don't think I get it. I thought, there's a line in
> src/config.h that's causing trouble. Started deleting lines in
> src/config.h, but then ended up deleting all lines in that file and
> still getting the same error
>
> So where am I supposed to look for this?
>
> A
Angus Leeming wrote:
Rob Lahaye wrote:
Hmmm, don't think I get it. I thought, there's a line in
src/config.h that's causing trouble. Started deleting lines in
src/config.h, but then ended up deleting all lines in that file and
still getting the same error
So where am I supposed to look for this
Rob Lahaye wrote:
>> #include
>> #include
>> int main() { return 0; }
>>
>> If you can do that without triggering the error, then I'm baffled.
>>
>> If you can't, then it makes sense to try and isolate the actual
>> #define that is causing the error.
>
> Surprise surprise. I have these lines
uintmax_t unsigned long long
#include
int main () { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/libs/regex/src -Isrc -Iboost \
-I/usr/local/include -I/usr/X11R6/include -fno-exceptions \
-W -Wall -c -o test.lo test.C
In file included from test.C:2:
boost/boost/cstdint.hpp:121: error: redeclar
nclude -I/usr/X11R6/include -fno-exceptions \
> -W -Wall -c -o test.lo test.C
> In file included from test.C:2:
> boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in
> type `long'
Ok, so the problem is that you have a 'uintmax_t' variable defined on
your
51 matches
Mail list logo
