-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 system but it isn't accessible through either stdint.h
e -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 system but it isn'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 boost/cstdint.hpp
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 lyx-top dir
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 boost/cstdint.hpp
int main() {
}
---
Is that enouthg to trigger it?
put the file in a lyx topdir and compile with g++ -W -Wall
-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: error
,
| from cpp_regex_traits.cpp:22:
| ../../../../boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in
| type `long'
So it is some combination of headers that cause this.
Please try this:
# include boost/regex/user.hpp
# include cstdlib
# include cstddef
# include cstdio
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 boost/regex/user.hpp
# include cstdlib
# include cstddef
# include cstdio
# include clocale
# include cassert
# include string
#
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 boost/regex/config.hpp
int main() { return 0; }
Compile with a suitably modified
$ g++ -Ipath to lyx
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 boost/regex/config.hpp
int
included 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=config.h from this line,
it compiles without error!!!
Does
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 boost/regex/config.hpp
int main() { return 0; }
So what happens if you #include *all* the system
headers of cpp_regex_traits.cpp
#include
-Iboost \
-I/usr/local/include -I/usr/X11R6/include
-DBOOST_USER_CONFIG=config.h \ -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
/regex/config.hpp:54,
from test.C:1:
boost/boost/cstdint.hpp:121: error: redeclaration of C++ built-in type `long'
--
$ grep ^# src/config.h
#ifndef _CONFIG_H
#define _CONFIG_H
#define AIKSAURUS_H_LOCATION
#define DEVEL_VERSION 1
#define ENABLE_ASSERTIONS 1
#define
Rob Lahaye wrote:
So what now happens if you reduce your test case to the more minimal
#include boost/cstdint.hpp
int main { return 0; }
where you compile with your 'lyx-style' command line invocation of g++?
Incidentally, Lars, if we pass -DBOOST_USER_CONFIG=config.h, why
do we add it to
Angus Leeming [EMAIL PROTECTED] writes:
| Rob Lahaye wrote:
| So what now happens if you reduce your test case to the more minimal
| #include boost/cstdint.hpp
| int main { return 0; }
| where you compile with your 'lyx-style' command line invocation of g++?
| Incidentally, Lars, if we pass
; }
$ g++33 -DHAVE_CONFIG_H -Iboost/libs/regex/src -Isrc -Iboost \
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h \
-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
Rob Lahaye wrote:
Once again: removing -DBOOST_USER_CONFIG=config.h from the
compile line above, solves the problem.
Does that bring us any closer?
Sure. Something in config.h is messing up the (quite small)
boost/cstdint.hpp
You should try and isolate the #define that is screwing things
Angus Leeming wrote:
Rob Lahaye wrote:
Once again: removing -DBOOST_USER_CONFIG=config.h from the
compile line above, solves the problem.
Does that bring us any closer?
Sure. Something in config.h is messing up the (quite small)
boost/cstdint.hpp
You should try and isolate the #define that
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?
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
Rob Lahaye wrote:
#include config.h
#include cstdint.hpp
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
uintmax_t unsigned long long
#include boost/cstdint.hpp
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
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
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++
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: error: redeclaration of C++ built-in
ty
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 included from ../../../../boost/boost/regex/config.hpp:54,
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
#
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
--
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; }
$
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 ring a
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
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
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
/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: removing -DBOOST_U
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
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?
>
>
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
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
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: redeclaration of C
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:
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 either.
| I need this,
-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: error: redeclaration of C++ built-in
type `long'
gmake[4]: *** [cpp_regex_traits.lo
:
| ../../../../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) [FreeBSD]
Ok, it must be FreeBSD that is the problem
Is uintmax_t a macro? Or uint32_t
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) [FreeBSD]
Ok, it must be FreeBSD that is the problem
Is uintmax_t
Rob Lahaye [EMAIL PROTECTED] writes:
Ok, it must be FreeBSD that is the problem
Is uintmax_t a macro? Or uint32_t?
Has inttypes.h on FreeBSD changed recently?
(upgraded libc perhaps?)
What is uintmax_t/uint32_t typdeffed/defined as in inttypes.h
| This is what I get:
| $ grep -n uintmax_t
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 version.
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 any
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 is
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 course
|
[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 is
|
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 your
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...)
It seems
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
: 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 inttypes.h on FreeBSD changed recently?
(upgraded libc perhaps?)
What is uintmax_t/uint32_t typdeffed/defined
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:
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
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: error: redeclaration of C++ built-in
type `long'
gmake[4]:
s.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) [FreeBSD]
Ok, it must be FreeBSD that is the "problem&q
om 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) [FreeBSD]
Ok, it must be FreeBSD that is the &quo
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
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...
>
|
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
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
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
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
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
[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
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
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
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++
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
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
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
1 - 100 of 102 matches
Mail list logo
