Re: Configure problems for lyx-140 on Mac
Andreas == Andreas Vox [EMAIL PROTECTED] writes: IMHO the only viable in-lyx solution is to disable concept-checking for darwin. Andreas What's wrong with my idea? It is too complicated. I know we have a lot of these clever hacks in the configure code (I am partly to blame for that), but we should avoid it as much as possible. What happens if we disable it for darwin? Well, the mac developpers will not some some specialized compile-time errors that the linux developers will see and fix anyway. Big deal... JMarc
Re: Configure problems for lyx-140 on Mac
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes: >> IMHO the only viable in-lyx solution is to disable concept-checking >> for darwin. Andreas> What's wrong with my idea? It is too complicated. I know we have a lot of these clever hacks in the configure code (I am partly to blame for that), but we should avoid it as much as possible. What happens if we disable it for darwin? Well, the mac developpers will not some some specialized compile-time errors that the linux developers will see and fix anyway. Big deal... JMarc
Re: Configure problems for lyx-140 on Mac
Andreas Vox wrote: Or do we already have a directory for this purpose? src/cheaders ? Argh, when do these get used? The cheaders/cctype headerfile looks quite different to my /usr/include/gcc/darwin/3.3/c++/cctype ! Of course it looks different, you noodle! These files exist to overcome a deficiency in some OS's header files. Why would this OS (older versions of Tru64 Unix for DEC Alphas) have the same deficiencies as your OS? So, specialise these header files for MacOS. Most will be #if defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__) #include path to perfectly good system cheader #else // insert existing contents of file here. #endif You'll put a little more magic into the cctype file of course. Something like #if defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__) #include path to system cctype #ifdef _D # undef _D #endif #ifdef _N # undef _N #endif #else // insert existing contents of file here. #endif -- Angus
Re: Configure problems for lyx-140 on Mac
Angus Leeming [EMAIL PROTECTED] writes: and put the corrected version in some directory XYZ in the LyX tree. Then all we Mac users would have to do is to add -isystem XYZ to the configure step. Or do we already have a directory for this purpose? | src/cheaders ? I am not fond of using these any more, we should try to get rid of them instead. IMHO the only viable in-lyx solution is to disable concept-checking for darwin. -- Lgb
Re: Configure problems for lyx-140 on Mac
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | src/cheaders ? Lars I am not fond of using these any more, we should try to get rid Lars of them instead. I was about to propose to get rid of them now. Lars IMHO the only viable in-lyx solution is to disable Lars concept-checking for darwin. Yes. JMarc
Re: Configure problems for lyx-140 on Mac
Andreas Vox wrote: Or do we already have a directory for this purpose? src/cheaders ? Argh, when do these get used? The cheaders/cctype headerfile looks quite different to my /usr/include/gcc/darwin/3.3/c++/cctype ! Of course it looks different, you noodle! These files exist to overcome a Ah, calling names now? (At least make it seasonal, you Weihnachtsmann! :-) ) deficiency in some OS's header files. Why would this OS (older versions of Tru64 Unix for DEC Alphas) have the same deficiencies as your OS? Well, what I _wanted_ to know is, if these files are supposed to be the same as the g++ include files. My version redefines the isalpha() macros etc. as proper functions and puts them into the std:: namespace, f.ex. So, specialise these header files for MacOS. Most will be I'd be more happy if these files didn't get included at all on Mac systems (and I dont think they are). #includectype.h is enough to break concept checking, and that's the only thing the LyX cctype and the Mac cctype have in common. I didn't look at the other files in cheaders/, but I'm afraid that including those wont improve matters on Mac. /Andreas
Re: Configure problems for lyx-140 on Mac
Lars writes: Angus Leeming [EMAIL PROTECTED] writes: and put the corrected version in some directory XYZ in the LyX tree. Then all we Mac users would have to do is to add -isystem XYZ to the configure step. Or do we already have a directory for this purpose? | src/cheaders ? I am not fond of using these any more, we should try to get rid of them instead. IMHO the only viable in-lyx solution is to disable concept-checking for darwin. What's wrong with my idea? As I understand it (please correct me), #include ... doesn't find any system headers and #include ... searches first any directories provided by -isystem, then the std system headers, then any directories given by -I. We would need to replace a std header file with a corrected version. I think it would be quite easy to provide a corrected version of bits/boost_concept_check.h for darwin (I compared this file with the one in the boost distribution and it looks that someone added underscores to the names of template arguments. Sometimes they also provided longer names, but sometimes they created the problematic names _R and _D. Since the ctype macros look older, I prefer changing the concept_check file). If we had a hierarchy cheaders/$ARCH/... , we could heal each OS specific deficiency without affecting other OSs (Until the GCC folks adopts this correction in _their_ header fixes. The ultimate goal would be to get cheaders/ empty). We could then add an -isystem option to CPPFLAGS if the subdirectory for the current architecture exists in cheaders/ I don't know how to change the configure file accordingly, but it shouldn't be more complicated than deactivating concept_checks for Mac, is it? /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox wrote: >> > Or do we already have a directory for this purpose? >> >> src/cheaders ? >> > Argh, when do these get used? The cheaders/cctype headerfile looks > quite different to my /usr/include/gcc/darwin/3.3/c++/cctype ! Of course it looks different, you noodle! These files exist to overcome a deficiency in some OS's header files. Why would this OS (older versions of Tru64 Unix for DEC Alphas) have the same deficiencies as your OS? So, specialise these header files for MacOS. Most will be #if defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__) #include #else // insert existing contents of file here. #endif You'll put a little more magic into the cctype file of course. Something like #if defined(macintosh) || defined(__APPLE__) || defined(__APPLE_CC__) #include #ifdef _D # undef _D #endif #ifdef _N # undef _N #endif #else // insert existing contents of file here. #endif -- Angus
Re: Configure problems for lyx-140 on Mac
Angus Leeming <[EMAIL PROTECTED]> writes: >> and put the corrected version in some directory XYZ in the LyX tree. >> Then all we Mac users would have to do is to add "-isystem XYZ" to the >> configure step. >> Or do we already have a directory for this purpose? > | src/cheaders ? I am not fond of using these any more, we should try to get rid of them instead. IMHO the only viable in-lyx solution is to disable concept-checking for darwin. -- Lgb
Re: Configure problems for lyx-140 on Mac
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | src/cheaders ? Lars> I am not fond of using these any more, we should try to get rid Lars> of them instead. I was about to propose to get rid of them now. Lars> IMHO the only viable in-lyx solution is to disable Lars> concept-checking for darwin. Yes. JMarc
Re: Configure problems for lyx-140 on Mac
Andreas Vox wrote: >> > Or do we already have a directory for this purpose? >> >> src/cheaders ? >> > Argh, when do these get used? The cheaders/cctype headerfile looks > quite different to my /usr/include/gcc/darwin/3.3/c++/cctype ! Of course it looks different, you noodle! These files exist to overcome a Ah, calling names now? (At least make it seasonal, you Weihnachtsmann! :-) ) deficiency in some OS's header files. Why would this OS (older versions of Tru64 Unix for DEC Alphas) have the same deficiencies as your OS? Well, what I _wanted_ to know is, if these files are supposed to be the same as the g++ include files. My version redefines the isalpha() macros etc. as proper functions and puts them into the std:: namespace, f.ex. So, specialise these header files for MacOS. Most will be I'd be more happy if these files didn't get included at all on Mac systems (and I dont think they are). #include is enough to break concept checking, and that's the only thing the LyX cctype and the Mac cctype have in common. I didn't look at the other files in cheaders/, but I'm afraid that including those wont improve matters on Mac. /Andreas
Re: Configure problems for lyx-140 on Mac
Lars writes: Angus Leeming <[EMAIL PROTECTED]> writes: >> and put the corrected version in some directory XYZ in the LyX tree. >> Then all we Mac users would have to do is to add "-isystem XYZ" to the >> configure step. >> Or do we already have a directory for this purpose? > | src/cheaders ? I am not fond of using these any more, we should try to get rid of them instead. IMHO the only viable in-lyx solution is to disable concept-checking for darwin. What's wrong with my idea? As I understand it (please correct me), #include "..." doesn't find any system headers and #include <...> searches first any directories provided by -isystem, then the std system headers, then any directories given by -I. We would need to replace a std header file with a corrected version. I think it would be quite easy to provide a corrected version of bits/boost_concept_check.h for darwin (I compared this file with the one in the boost distribution and it looks that someone added underscores to the names of template arguments. Sometimes they also provided longer names, but sometimes they created the problematic names _R and _D. Since the ctype macros look older, I prefer changing the concept_check file). If we had a hierarchy cheaders/$ARCH/... , we could heal each OS specific deficiency without affecting other OSs (Until the GCC folks adopts this correction in _their_ header fixes. The ultimate goal would be to get cheaders/ empty). We could then add an -isystem option to CPPFLAGS if the subdirectory for the current architecture exists in cheaders/ I don't know how to change the configure file accordingly, but it shouldn't be more complicated than deactivating concept_checks for Mac, is it? /Andreas
Re: Configure problems for lyx-140 on Mac
Lars Gullik Bjnnes [EMAIL PROTECTED] writes: So this should absolutely be reported to apple. Then they can fix it. I just did that. (problem ID 3932345, if anyone cares) While we wait on Apple to fix this, couldn't we use the wonderful and apparently indispensable -isystem option of GCC? We could fix the bug ourselves either in ctype.h or boost_concept_check.h and put the corrected version in some directory XYZ in the LyX tree. Then all we Mac users would have to do is to add -isystem XYZ to the configure step. Or do we already have a directory for this purpose? BTW, wouldn't it be possible to include Florence' LyX Skeleton and the extra configure options to the CVS version? We poor Mac users need an extra download and a call to configure with four lines of options as it is now. (yes I know, I'm whining :-) ) /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox wrote: So this should absolutely be reported to apple. Then they can fix it. I just did that. (problem ID 3932345, if anyone cares) While we wait on Apple to fix this, couldn't we use the wonderful and apparently indispensable -isystem option of GCC? We could fix the bug ourselves either in ctype.h or boost_concept_check.h It seems to me that we have control over the contents of boost_concept_check.h, even if Lars would prefer not to alter these boost files at all. I think that it's most pragmatic to add some preprocessor magic to this file. and put the corrected version in some directory XYZ in the LyX tree. Then all we Mac users would have to do is to add -isystem XYZ to the configure step. Or do we already have a directory for this purpose? src/cheaders ? -- Angus
Re: Configure problems for lyx-140 on Mac
Angus Leeming [EMAIL PROTECTED] writes: It seems to me that we have control over the contents of boost_concept_check.h, Hmm, I need sudo if I want to change the contents of /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h This was incorporated into GCC and is not in lyx-devel/boost/ and put the corrected version in some directory XYZ in the LyX tree. Then all we Mac users would have to do is to add -isystem XYZ to the configure step. Or do we already have a directory for this purpose? src/cheaders ? Argh, when do these get used? The cheaders/cctype headerfile looks quite different to my /usr/include/gcc/darwin/3.3/c++/cctype ! /Andreas
Re: Configure problems for lyx-140 on Mac
Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes: > > So this should absolutely be reported to apple. Then they can fix it. I just did that. (problem ID 3932345, if anyone cares) While we wait on Apple to fix this, couldn't we use the wonderful and apparently indispensable "-isystem" option of GCC? We could fix the bug ourselves either in ctype.h or boost_concept_check.h and put the corrected version in some directory XYZ in the LyX tree. Then all we Mac users would have to do is to add "-isystem XYZ" to the configure step. Or do we already have a directory for this purpose? BTW, wouldn't it be possible to include Florence' LyX Skeleton and the extra configure options to the CVS version? We poor Mac users need an extra download and a call to configure with four lines of options as it is now. (yes I know, I'm whining :-) ) /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox wrote: >> So this should absolutely be reported to apple. Then they can fix it. > > I just did that. (problem ID 3932345, if anyone cares) > > While we wait on Apple to fix this, couldn't we use the wonderful > and apparently indispensable "-isystem" option of GCC? > > We could fix the bug ourselves either in ctype.h or boost_concept_check.h It seems to me that we have control over the contents of boost_concept_check.h, even if Lars would prefer not to alter these boost files at all. I think that it's most pragmatic to add some preprocessor magic to this file. > and put the corrected version in some directory XYZ in the LyX tree. > Then all we Mac users would have to do is to add "-isystem XYZ" to the > configure step. > Or do we already have a directory for this purpose? src/cheaders ? -- Angus
Re: Configure problems for lyx-140 on Mac
Angus Leeming <[EMAIL PROTECTED]> writes: > > It seems to me that we have control over the contents of > boost_concept_check.h, Hmm, I need sudo if I want to change the contents of /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h This was incorporated into GCC and is not in lyx-devel/boost/ > > > and put the corrected version in some directory XYZ in the LyX tree. > > Then all we Mac users would have to do is to add "-isystem XYZ" to the > > configure step. > > Or do we already have a directory for this purpose? > > src/cheaders ? > Argh, when do these get used? The cheaders/cctype headerfile looks quite different to my /usr/include/gcc/darwin/3.3/c++/cctype ! /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox [EMAIL PROTECTED] writes: So the errormessage seems justified and we only have to find out which red-dripping includefile defined _D and _R ... | Ok, I found it. It's in /usr/include/ctype.h under the heading | /* backward compatibility */ -- hahaha, what about forward | compability? | Lars, Jean_Marc, what would be the best solution: | 1 - change include order (if possible) might work. Where is this ctype included from? Our code or library code? Does using cctype working better? | 2 - undef _D and _R after ctype.h was included ugly bugly | 3 - make a patch for Boost Not Boost, but GCC. The concept checks originally comes from boost, but they have been copied into GCC (libstc++). So it should be reported there. | 4 - make a patch for Apples ctype.h Yes, or at least make them aware of trhe -- Lgb
Re: Configure problems for lyx-140 on Mac
Lars Gullik Bjnnes [EMAIL PROTECTED] writes: Andreas Vox [EMAIL PROTECTED] writes: | 1 - change include order (if possible) might work. Where is this ctype included from? Our code or library code? ./configure does not include ctype directly, I traced it back to ctype.h - cctype -iosfwd - ios, string, streambuf, bits/stl_algobase.h Does using cctype working better? cctype includes ctype.h I guess cctype is the best place to correct this problem, cctype already has a section for Mac where they #undef the isalpha() Macros and the like. | 2 - undef _D and _R after ctype.h was included ugly bugly But it seems to work (I only tested the file created by ./configure), if you put something like #include ctype.h #undef _R #undef _D in front of the other includes. Is there a canonical place for LyX where we could put this? So I can test if it breaks anything else? /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox [EMAIL PROTECTED] writes: | ./configure does not include ctype directly, I traced it back to | ctype.h - cctype -iosfwd - ios, string, streambuf, bits/stl_algobase.h Does using cctype working better? | cctype includes ctype.h | I guess cctype is the best place to correct this problem, cctype already | has a section for Mac where they #undef the isalpha() Macros and the like. So this should absolutely be reported to apple. Then they can fix it. | 2 - undef _D and _R after ctype.h was included ugly bugly | But it seems to work (I only tested the file created by ./configure), if you | put something like | #include ctype.h | #undef _R | #undef _D | in front of the other includes. Sure it will work... but then why not just comment out the backwards compability stuff in ctype.h? | Is there a canonical place for LyX where we could put this? | So I can test if it breaks anything else? Not really... Only if you do it in config.h, making ctype.h being included in all files. -- Lgb
Re: Configure problems for lyx-140 on Mac
Andreas Vox <[EMAIL PROTECTED]> writes: >> So the errormessage seems justified and we only have to find >> out which red-dripping includefile defined _D and _R ... > | Ok, I found it. It's in /usr/include/ctype.h under the heading | /* backward compatibility */ -- hahaha, what about forward | compability? > | Lars, Jean_Marc, what would be the best solution: > | 1 - change include order (if possible) might work. Where is this ctype included from? Our code or library code? Does using working better? | 2 - undef _D and _R after ctype.h was included ugly bugly | 3 - make a patch for Boost Not Boost, but GCC. The concept checks originally comes from boost, but they have been copied into GCC (libstc++). So it should be reported there. | 4 - make a patch for Apples ctype.h Yes, or at least make them aware of trhe -- Lgb
Re: Configure problems for lyx-140 on Mac
Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes: > > Andreas Vox <[EMAIL PROTECTED]> writes: > > > | 1 - change include order (if possible) > > might work. Where is this ctype included from? Our code or library > code? ./configure does not include directly, I traced it back to ctype.h <- cctype <-iosfwd <- ios, string, streambuf, bits/stl_algobase.h > > Does using working better? includes I guess is the best place to correct this problem, cctype already has a section for Mac where they #undef the isalpha() Macros and the like. > > | 2 - undef _D and _R after ctype.h was included > > ugly bugly But it seems to work (I only tested the file created by ./configure), if you put something like #include #undef _R #undef _D in front of the other includes. Is there a canonical place for LyX where we could put this? So I can test if it breaks anything else? /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox <[EMAIL PROTECTED]> writes: | ./configure does not include directly, I traced it back to | ctype.h <- cctype <-iosfwd <- ios, string, streambuf, bits/stl_algobase.h > >> >> Does using working better? > | includes | I guess is the best place to correct this problem, cctype already | has a section for Mac where they #undef the isalpha() Macros and the like. So this should absolutely be reported to apple. Then they can fix it. >> >> | 2 - undef _D and _R after ctype.h was included >> >> ugly bugly > | But it seems to work (I only tested the file created by ./configure), if you | put something like > | #include | #undef _R | #undef _D > | in front of the other includes. Sure it will work... but then why not just comment out the "backwards compability" stuff in ctype.h? | Is there a canonical place for LyX where we could put this? | So I can test if it breaks anything else? Not really... Only if you do it in config.h, making ctype.h being included in all files. -- Lgb
Re: Configure problems for lyx-140 on Mac
Andreas == Andreas Vox [EMAIL PROTECTED] writes: Lars, we need some help from you I guess. The error says: configure:4923: checking istream usability configure:4936: g++ -c -g -Os -fno-exceptions -W -Wall conftest.cc 5 In file included from /usr/include/gcc/darwin/3.3/c++/bits/concept_check.h:60, from /usr/include/gcc/darwin/3.3/c++/bits/stl_iterator_base_fun cs.h:68, from /usr/include/gcc/darwin/3.3/c++/bits/stl_algobase.h:74, from /usr/include/gcc/darwin/3.3/c++/memory:54, from /usr/include/gcc/darwin/3.3/c++/string:48, from /usr/include/gcc/darwin/3.3/c++/bits/locale_classes.h:47, from /usr/include/gcc/darwin/3.3/c++/bits/ios_base.h:47, from /usr/include/gcc/darwin/3.3/c++/ios:49, from /usr/include/gcc/darwin/3.3/c++/istream:44, from configure:4987: /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_InputIteratorConcept_Tp::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:415: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:417: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_ForwardIteratorConcept_Tp::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:450: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_RandomAccessIteratorConcept_Tp::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:502: error: parse error before `;' token So the problem is with the new concept check support. JMarc
Re: Configure problems for lyx-140 on Mac
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Andreas == Andreas Vox [EMAIL PROTECTED] writes: | Lars, we need some help from you I guess. The error says: g++ on darwin is botched? Turn off concept checking for darwin? | So the problem is with the new concept check support. or darwin... -- Lgb
Re: Configure problems for lyx-140 on Mac
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars, we need some help from you I guess. The error says: Lars g++ on darwin is botched? Lars Turn off concept checking for darwin? Maybe. How should that be done? | So the problem is with the new concept check support. Lars or darwin... Sure, this was not supposed to be a vivious atack against concept checking. JMarc
Re: Configure problems for lyx-140 on Mac
Lars Gullik Bjnnes [EMAIL PROTECTED] writes:
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars, we need some help from you I guess. The error says:
g++ on darwin is botched?
Turn off concept checking for darwin?
| So the problem is with the new concept check support.
or darwin...
I made more inquiries. The offending code in gcc/.../boost_concept_check.h is:
(I guess some C++ afficionados know what this is about, I don't)
__
template class _Tp
struct _InputIteratorConcept
{
void __constraints() {
__function_requires _TrivialIteratorConcept_Tp ();
// require iterator_traits typedef's
typedef typename std::iterator_traits_Tp::difference_type _D;
//
// __function_requires _SignedIntegerConcept_D ();
typedef typename std::iterator_traits_Tp::reference _R;
//
typedef typename std::iterator_traits_Tp::pointer _Pt;
typedef typename std::iterator_traits_Tp::iterator_category _Cat;
__function_requires _ConvertibleConcept
typename std::iterator_traits_Tp::iterator_category,
std::input_iterator_tag ();
++__i;// require preincrement operator
__i++;// require postincrement operator
}
_Tp __i;
};
__
After preprocessing (gcc -E) this looks like this:
__
struct _InputIteratorConcept
{
void __constraints() {
__function_requires _TrivialIteratorConcept_Tp ();
typedef typename std::iterator_traits_Tp::difference_type 0x0400L;
//
typedef typename std::iterator_traits_Tp::reference 0x0004L; //
typedef typename std::iterator_traits_Tp::pointer _Pt;
typedef typename std::iterator_traits_Tp::iterator_category _Cat;
__function_requires _ConvertibleConcept
typename std::iterator_traits_Tp::iterator_category,
std::input_iterator_tag ();
++__i;
__i++;
}
_Tp __i;
};
__
So the errormessage seems justified and we only have to find
out which red-dripping includefile defined _D and _R ...
(Did I mention recently that I prefer Java over C++ ?)
Cheers
/Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox [EMAIL PROTECTED] writes:
I made more inquiries. The offending code in gcc/.../boost_concept_check.h is:
(I guess some C++ afficionados know what this is about, I don't)
__
template class _Tp
struct _InputIteratorConcept
{
void __constraints() {
__function_requires _TrivialIteratorConcept_Tp ();
// require iterator_traits typedef's
typedef typename std::iterator_traits_Tp::difference_type _D; //
// __function_requires _SignedIntegerConcept_D ();
typedef typename std::iterator_traits_Tp::reference _R;//
...
So the errormessage seems justified and we only have to find
out which red-dripping includefile defined _D and _R ...
Ok, I found it. It's in /usr/include/ctype.h under the heading
/* backward compatibility */ -- hahaha, what about forward
compability?
Lars, Jean_Marc, what would be the best solution:
1 - change include order (if possible)
2 - undef _D and _R after ctype.h was included
3 - make a patch for Boost
4 - make a patch for Apples ctype.h
Well, I guess 1) might not work and 4) will take to long to
wait for. Let me know if I should test a solution.
/Andreas
Re: Configure problems for lyx-140 on Mac
> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes: Lars, we need some help from you I guess. The error says: configure:4923: checking istream usability configure:4936: g++ -c -g -Os -fno-exceptions -W -Wall conftest.cc >&5 In file included from /usr/include/gcc/darwin/3.3/c++/bits/concept_check.h:60, from /usr/include/gcc/darwin/3.3/c++/bits/stl_iterator_base_fun cs.h:68, from /usr/include/gcc/darwin/3.3/c++/bits/stl_algobase.h:74, from /usr/include/gcc/darwin/3.3/c++/memory:54, from /usr/include/gcc/darwin/3.3/c++/string:48, from /usr/include/gcc/darwin/3.3/c++/bits/locale_classes.h:47, from /usr/include/gcc/darwin/3.3/c++/bits/ios_base.h:47, from /usr/include/gcc/darwin/3.3/c++/ios:49, from /usr/include/gcc/darwin/3.3/c++/istream:44, from configure:4987: /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_InputIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:415: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:417: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_ForwardIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:450: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_RandomAccessIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:502: error: parse error before `;' token So the problem is with the new concept check support. JMarc
Re: Configure problems for lyx-140 on Mac
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Andreas" == Andreas Vox <[EMAIL PROTECTED]> writes: > | Lars, we need some help from you I guess. The error says: g++ on darwin is botched? Turn off concept checking for darwin? | So the problem is with the new concept check support. or darwin... -- Lgb
Re: Configure problems for lyx-140 on Mac
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | Lars, we need some help from you I guess. The error says: Lars> g++ on darwin is botched? Lars> Turn off concept checking for darwin? Maybe. How should that be done? | So the problem is with the new concept check support. Lars> or darwin... Sure, this was not supposed to be a vivious atack against concept checking. JMarc
Re: Configure problems for lyx-140 on Mac
Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes:
>
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | Lars, we need some help from you I guess. The error says:
>
> g++ on darwin is botched?
>
> Turn off concept checking for darwin?
>
> | So the problem is with the new concept check support.
>
> or darwin...
I made more inquiries. The offending code in gcc/.../boost_concept_check.h is:
(I guess some C++ afficionados know what this is about, I don't)
__
template
struct _InputIteratorConcept
{
void __constraints() {
__function_requires< _TrivialIteratorConcept<_Tp> >();
// require iterator_traits typedef's
typedef typename std::iterator_traits<_Tp>::difference_type _D;
//<<
// __function_requires< _SignedIntegerConcept<_D> >();
typedef typename std::iterator_traits<_Tp>::reference _R;
//<<
typedef typename std::iterator_traits<_Tp>::pointer _Pt;
typedef typename std::iterator_traits<_Tp>::iterator_category _Cat;
__function_requires< _ConvertibleConcept<
typename std::iterator_traits<_Tp>::iterator_category,
std::input_iterator_tag> >();
++__i;// require preincrement operator
__i++;// require postincrement operator
}
_Tp __i;
};
__
After preprocessing (gcc -E) this looks like this:
__
struct _InputIteratorConcept
{
void __constraints() {
__function_requires< _TrivialIteratorConcept<_Tp> >();
typedef typename std::iterator_traits<_Tp>::difference_type 0x0400L;
//<<<
typedef typename std::iterator_traits<_Tp>::reference 0x0004L; //<<<
typedef typename std::iterator_traits<_Tp>::pointer _Pt;
typedef typename std::iterator_traits<_Tp>::iterator_category _Cat;
__function_requires< _ConvertibleConcept<
typename std::iterator_traits<_Tp>::iterator_category,
std::input_iterator_tag> >();
++__i;
__i++;
}
_Tp __i;
};
__
So the errormessage seems justified and we only have to find
out which red-dripping includefile defined _D and _R ...
(Did I mention recently that I prefer Java over C++ ?)
Cheers
/Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox <[EMAIL PROTECTED]> writes:
>
> I made more inquiries. The offending code in gcc/.../boost_concept_check.h is:
> (I guess some C++ afficionados know what this is about, I don't)
>
> __
template
struct _InputIteratorConcept
{
void __constraints() {
__function_requires< _TrivialIteratorConcept<_Tp> >();
// require iterator_traits typedef's
typedef typename std::iterator_traits<_Tp>::difference_type _D; //<<
// __function_requires< _SignedIntegerConcept<_D> >();
typedef typename std::iterator_traits<_Tp>::reference _R;//<<
...
> So the errormessage seems justified and we only have to find
> out which red-dripping includefile defined _D and _R ...
Ok, I found it. It's in /usr/include/ctype.h under the heading
/* backward compatibility */ -- hahaha, what about forward
compability?
Lars, Jean_Marc, what would be the best solution:
1 - change include order (if possible)
2 - undef _D and _R after ctype.h was included
3 - make a patch for Boost
4 - make a patch for Apples ctype.h
Well, I guess 1) might not work and 4) will take to long to
wait for. Let me know if I should test a solution.
/Andreas
Re: Configure problems for lyx-140 on Mac
On Freitag 17 Dezember 2004 04:47, Andreas Vox wrote: Angus Leeming [EMAIL PROTECTED] writes: Bennett Helm wrote: Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning configure, which fails. I get variants of the following error with each of ostream, istream, sstream, locale, ios, and Aiksaurus: Same with me. Try running $ ./autogen.sh $ ./configure your options Doesn't make a difference (well, it does, before the make failed with: I had the same problem ... removing all autoconf caches cured it ./lib/reLyX/autom4te.cache ./autom4te.cache Kornel -- Kornel Benko [EMAIL PROTECTED]
Re: Configure problems for lyx-140 on Mac
Kornel Benko [EMAIL PROTECTED] writes: Try running $ ./autogen.sh $ ./configure your options Doesn't make a difference (well, it does, before the make failed with: [other problem] I had the same problem ... removing all autoconf caches cured it ./lib/reLyX/autom4te.cache ./autom4te.cache autogen.sh already cured that already. It doesn't help with Bennet's probelm: unusable istream/ostream/etc. libraries It looks as if either the new boost version or this concept checking breaks on Mac. Any help there? /Andreas
Re: Configure problems for lyx-140 on Mac
On Freitag 17 Dezember 2004 04:47, Andreas Vox wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > > > > Bennett Helm wrote: > > > > > Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning > > > configure, which fails. I get variants of the following error with each > > > of ostream, istream, sstream, locale, ios, and Aiksaurus: > > Same with me. > > > > > Try running > > > > $ ./autogen.sh > > $ ./configure > > Doesn't make a difference (well, it does, before the make failed > with: I had the same problem ... removing all autoconf caches cured it ./lib/reLyX/autom4te.cache ./autom4te.cache Kornel -- Kornel Benko [EMAIL PROTECTED]
Re: Configure problems for lyx-140 on Mac
Kornel Benko <[EMAIL PROTECTED]> writes: > > > Try running > > > > > > $ ./autogen.sh > > > $ ./configure > > > > Doesn't make a difference (well, it does, before the make failed > > with: [other problem] > I had the same problem ... removing all autoconf caches cured it > > ./lib/reLyX/autom4te.cache > ./autom4te.cache autogen.sh already cured that already. It doesn't help with Bennet's probelm: unusable istream/ostream/etc. libraries It looks as if either the new boost version or this "concept checking" breaks on Mac. Any help there? /Andreas
Configure problems for lyx-140 on Mac
Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning configure, which fails. I get variants of the following error with each of ostream, istream, sstream, locale, ios, and Aiksaurus: checking ostream usability... no checking ostream presence... yes configure: WARNING: ostream: present but cannot be compiled configure: WARNING: ostream: check for missing prerequisite headers? configure: WARNING: ostream: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for ostream... yes The result is a failure to find the Qt library name. I'm using gcc-3.3 (the latest version from Apple, which I installed several weeks ago, with no problems then). (These problems do not occur for gcc-3.1.) Any suggestions? Thanks. Bennett
Re: Configure problems for lyx-140 on Mac
Bennett Helm wrote: Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning configure, which fails. I get variants of the following error with each of ostream, istream, sstream, locale, ios, and Aiksaurus: checking ostream usability... no checking ostream presence... yes configure: WARNING: ostream: present but cannot be compiled configure: WARNING: ostream: check for missing prerequisite headers? configure: WARNING: ostream: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for ostream... yes The result is a failure to find the Qt library name. I'm using gcc-3.3 (the latest version from Apple, which I installed several weeks ago, with no problems then). (These problems do not occur for gcc-3.1.) Any suggestions? Try running $ ./autogen.sh $ ./configure your options explicitly. If that doesn't work, try backing out the recent changes to configure.ac $ cvs -q diff -r 1.30 configure.ac tmp.diff $ patch -p0 -R tmp.diff $ ./autogen.sh $ ./configure your options (Although I can't see what difference that would make.) -- Angus
Re: Configure problems for lyx-140 on Mac
Angus Leeming [EMAIL PROTECTED] writes: Bennett Helm wrote: Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning configure, which fails. I get variants of the following error with each of ostream, istream, sstream, locale, ios, and Aiksaurus: Same with me. Try running $ ./autogen.sh $ ./configure your options Doesn't make a difference (well, it does, before the make failed with: cd . /bin/sh /Users/vox/LYX/lyx-devel/config/missing --run aclocal-1.6 -I m4 cd . \ /bin/sh /Users/vox/LYX/lyx-devel/config/missing --run automake-1.6 --foreign Makefile cd . /bin/sh /Users/vox/LYX/lyx-devel/config/missing --run autoconf configure.ac:270: error: possibly undefined macro: AC_FUNC_MKDIR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [configure] Error 1 ___ After auogen.sh I get Bennets errors) I checked the config.log file and it says: ___ configure:4923: checking istream usability configure:4936: g++ -c -g -Os -fno-exceptions -W -Wall conftest.cc 5 In file included from /usr/include/gcc/darwin/3.3/c++/bits/concept_check.h:60, from /usr/include/gcc/darwin/3.3/c++/bits/stl_iterator_base_fun cs.h:68, from /usr/include/gcc/darwin/3.3/c++/bits/stl_algobase.h:74, from /usr/include/gcc/darwin/3.3/c++/memory:54, from /usr/include/gcc/darwin/3.3/c++/string:48, from /usr/include/gcc/darwin/3.3/c++/bits/locale_classes.h:47, from /usr/include/gcc/darwin/3.3/c++/bits/ios_base.h:47, from /usr/include/gcc/darwin/3.3/c++/ios:49, from /usr/include/gcc/darwin/3.3/c++/istream:44, from configure:4987: /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_InputIteratorConcept_Tp::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:415: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:417: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_ForwardIteratorConcept_Tp::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:450: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_RandomAccessIteratorConcept_Tp::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:502: error: parse error before `;' token configure:4939: $? = 1 configure: failed program was: | #line 4925 configure | /* confdefs.h. */ | | #define PACKAGE_NAME lyx | #define PACKAGE_TARNAME lyx | #define PACKAGE_VERSION 1.4.0cvs | #define PACKAGE_STRING lyx 1.4.0cvs | #define PACKAGE_BUGREPORT [EMAIL PROTECTED] | #define DEVEL_VERSION 1 | #define PACKAGE lyx | #define VERSION 1.4.0cvs | #define HAVE_KPSEWHICH 1 | #ifdef __cplusplus | #include stdlib.h | #endif | #define WITH_WARNINGS 1 | #define _GLIBCPP_CONCEPT_CHECKS 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_OSTREAM 1 | /* end confdefs.h. */ | #include stdio.h | #if HAVE_SYS_TYPES_H | # include sys/types.h | #endif | #if HAVE_SYS_STAT_H | # include sys/stat.h | #endif | #if STDC_HEADERS | # include stdlib.h | # include stddef.h | #else | # if HAVE_STDLIB_H | # include stdlib.h | # endif | #endif | #if HAVE_STRING_H | # if !STDC_HEADERS HAVE_MEMORY_H | # include memory.h | # endif | # include string.h | #endif | #if HAVE_STRINGS_H | # include strings.h | #endif | #if HAVE_INTTYPES_H | # include inttypes.h | #else | # if HAVE_STDINT_H | # include stdint.h | # endif | #endif | #if HAVE_UNISTD_H | # include unistd.h | #endif | #include istream configure:4955: result: no configure:4959: checking istream presence __ So: Boost? Concept checks? Anyone any idea? /Andreas
Configure problems for lyx-140 on Mac
Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning configure, which fails. I get variants of the following error with each of ostream, istream, sstream, locale, ios, and Aiksaurus: checking ostream usability... no checking ostream presence... yes configure: WARNING: ostream: present but cannot be compiled configure: WARNING: ostream: check for missing prerequisite headers? configure: WARNING: ostream: proceeding with the preprocessor's result configure: WARNING: ## ## configure: WARNING: ## Report this to [EMAIL PROTECTED] ## configure: WARNING: ## ## checking for ostream... yes The result is a failure to find the Qt library name. I'm using gcc-3.3 (the latest version from Apple, which I installed several weeks ago, with no problems then). (These problems do not occur for gcc-3.1.) Any suggestions? Thanks. Bennett
Re: Configure problems for lyx-140 on Mac
Bennett Helm wrote: > Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning > configure, which fails. I get variants of the following error with each > of ostream, istream, sstream, locale, ios, and Aiksaurus: > > checking ostream usability... no > checking ostream presence... yes > configure: WARNING: ostream: present but cannot be compiled > configure: WARNING: ostream: check for missing prerequisite headers? > configure: WARNING: ostream: proceeding with the preprocessor's result > configure: WARNING: ## ## > configure: WARNING: ## Report this to > [EMAIL PROTECTED] ## > configure: WARNING: ## ## > checking for ostream... yes > > The result is a failure to find the Qt library name. > > I'm using gcc-3.3 (the latest version from Apple, which I installed > several weeks ago, with no problems then). (These problems do not occur > for gcc-3.1.) > > Any suggestions? Try running $ ./autogen.sh $ ./configure explicitly. If that doesn't work, try backing out the recent changes to configure.ac $ cvs -q diff -r 1.30 configure.ac > tmp.diff $ patch -p0 -R < tmp.diff $ ./autogen.sh $ ./configure (Although I can't see what difference that would make.) -- Angus
Re: Configure problems for lyx-140 on Mac
Angus Leeming <[EMAIL PROTECTED]> writes: > > Bennett Helm wrote: > > > Trying to build the latest CVS of lyx-140 in Mac OS X forced rerunning > > configure, which fails. I get variants of the following error with each > > of ostream, istream, sstream, locale, ios, and Aiksaurus: Same with me. > > Try running > > $ ./autogen.sh > $ ./configure Doesn't make a difference (well, it does, before the make failed with: cd . && /bin/sh /Users/vox/LYX/lyx-devel/config/missing --run aclocal-1.6 -I m4 cd . && \ /bin/sh /Users/vox/LYX/lyx-devel/config/missing --run automake-1.6 --foreign Makefile cd . && /bin/sh /Users/vox/LYX/lyx-devel/config/missing --run autoconf configure.ac:270: error: possibly undefined macro: AC_FUNC_MKDIR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [configure] Error 1 ___ After auogen.sh I get Bennets errors) I checked the config.log file and it says: ___ configure:4923: checking istream usability configure:4936: g++ -c -g -Os -fno-exceptions -W -Wall conftest.cc >&5 In file included from /usr/include/gcc/darwin/3.3/c++/bits/concept_check.h:60, from /usr/include/gcc/darwin/3.3/c++/bits/stl_iterator_base_fun cs.h:68, from /usr/include/gcc/darwin/3.3/c++/bits/stl_algobase.h:74, from /usr/include/gcc/darwin/3.3/c++/memory:54, from /usr/include/gcc/darwin/3.3/c++/string:48, from /usr/include/gcc/darwin/3.3/c++/bits/locale_classes.h:47, from /usr/include/gcc/darwin/3.3/c++/bits/ios_base.h:47, from /usr/include/gcc/darwin/3.3/c++/ios:49, from /usr/include/gcc/darwin/3.3/c++/istream:44, from configure:4987: /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_InputIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:415: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:417: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_ForwardIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:450: error: parse error before `;' token /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h: In member function `void __gnu_cxx::_RandomAccessIteratorConcept<_Tp>::__constraints()': /usr/include/gcc/darwin/3.3/c++/bits/boost_concept_check.h:502: error: parse error before `;' token configure:4939: $? = 1 configure: failed program was: | #line 4925 "configure" | /* confdefs.h. */ | | #define PACKAGE_NAME "lyx" | #define PACKAGE_TARNAME "lyx" | #define PACKAGE_VERSION "1.4.0cvs" | #define PACKAGE_STRING "lyx 1.4.0cvs" | #define PACKAGE_BUGREPORT "[EMAIL PROTECTED]" | #define DEVEL_VERSION 1 | #define PACKAGE "lyx" | #define VERSION "1.4.0cvs" | #define HAVE_KPSEWHICH 1 | #ifdef __cplusplus | #include | #endif | #define WITH_WARNINGS 1 | #define _GLIBCPP_CONCEPT_CHECKS 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_OSTREAM 1 | /* end confdefs.h. */ | #include | #if HAVE_SYS_TYPES_H | # include | #endif | #if HAVE_SYS_STAT_H | # include | #endif | #if STDC_HEADERS | # include | # include | #else | # if HAVE_STDLIB_H | # include | # endif | #endif | #if HAVE_STRING_H | # if !STDC_HEADERS && HAVE_MEMORY_H | # include | # endif | # include | #endif | #if HAVE_STRINGS_H | # include | #endif | #if HAVE_INTTYPES_H | # include | #else | # if HAVE_STDINT_H | # include | # endif | #endif | #if HAVE_UNISTD_H | # include | #endif | #include configure:4955: result: no configure:4959: checking istream presence __ So: Boost? Concept checks? Anyone any idea? /Andreas
