Re: The LyX licence

[Rob Lahaye]

Dear members of the LyX-team,

I hereby grant permission to licence everything I have contributed
to LyX under the Gnu General Public Licence, version 2 or later.

Regards,
Rob Lahaye.

Re: The LyX licence

[Rob Lahaye]

Dear members of the LyX-team,

I hereby grant permission to licence everything I have contributed
to LyX under the Gnu General Public Licence, version 2 or later.

Regards,
Rob Lahaye.

Re: FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
Rob == Rob Lahaye [EMAIL PROTECTED] writes:


 Rob I can compile LyX almost; something goes wrong at the very end.
 Rob At the end of gmake, when the final executable is being linked, I
 Rob get zillions of following lines:

 Rob $ gmake [...]
 Rob
BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE9_M_insertENS_14_List_iteratorIS1_EERKS1_+0x19):
 Rob In function `__gnu_norm::list

::_M_insert(__gnu_norm::_List_iterator, Branch const)':


 Do you have one of these things defined in config.h?

 /* libstdc++ concept checking */
 #undef _GLIBCPP_CONCEPT_CHECKS

 /* libstdc++ concept checking */
 #undef _GLIBCXX_CONCEPT_CHECKS

 /* libstdc++ debug mode */
 #undef _GLIBCXX_DEBUG

 /* libstdc++ pedantic debug mode */
 #undef _GLIBCXX_DEBUG_PEDANTIC

 Could you test what happens when turning them off?

Yep, that solves the problem; not that I know what I'm doing though.
But LyX compiles like a charm!

Can you explain a little? Is this a bug, or a misbehaving feature
of FreeBSD, or perhaps LyX or gcc?

Even more important: how can I tell the configure script to never
set these #def directives again in the future?

Thanks!
Rob.

New Userdir: [Create directory] and [Exit LyX] buttons mixed up?

[Rob Lahaye]

Hi,

I start LyX-cvs like this:

 $ src/lyx -userdir /tmp/LyX

Because /tmp/LyX does not exist, a dialog appears with

  You have specified a non-existent user LyX
 directory, /tmp/LyX.
  It is needed to keep your own configuration.
  [Create directory][Exit LyX]

I then click on [Create directory], but LyX seems to just
exit without any message. The directory is not created.

HOWEVER, if I click on [Exit LyX], then LyX creates the
directory and continues.

Apparently the function of the two buttons are mixed up here.

Rob.

Re: FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
 Rob Lahaye writes:

 Rob Yep, that solves the problem; not that I know what I'm doing
 Rob though. But LyX compiles like a charm!

 Rob Can you explain a little? Is this a bug, or a misbehaving feature
 Rob of FreeBSD, or perhaps LyX or gcc?

 I think this is a bug of gcc on freebsd. These things turn on some
 recent (gcc 3.3 or 3.4) debug features of the C++ standard library.

 It seems that at least one of these is broken. If you have time, you
 could try to turn them off one by one and see which one is the
 culprit.

It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC.


 Rob Even more important: how can I tell the configure script to never
 Rob set these #def directives again in the future?

 use --disable-stdlib-debug and/or --disable-concept-checks.

Using --disable-stdlib-debug is enough to solve the problem.


Does that make sense?

Rob.

View-Postscript error: use --swap instead of -swap

[Rob Lahaye]

Hi,

My LyX, by default, uses for Postscript viewing gv -swap
(as in Tools-Preferences-Conversion-Formats, Postscript)

However, eversince I upgraded to gv version 3.6.1, the -swap does
not work anymore, and consequently, Postscript viewing with LyX is
not working (not working with out-of-the box configuration, that is).

I have to modify -swap to --swap in the preferences settings.
Then it's OK again.

Has nobody else with up-to-date gv, trouble with this?

I wonder, whether LyX-CVS by default, should choose to support latest
gv version. People with older gv, can then modify the preferences, or
upgrade to newer gv.
By the time the next LyX is released, it may not work with common version
of gv of that time, maybe.

Rob.

Re: FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
 Rob It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC.

 Rob Does that make sense?

 So the stdlibc++ debug feature is broken with your compiler version, I
 guess. You should ask the freebsd people for more info. When we know
 exactly what happens, we can maybe blacklist some freebsd/gcc combo in
 the code that enables debug.

 What is your gcc version?

It's 3.4.2.
This version ships with FreeBSD 5.3 (latest release).
This version of gcc may be the default compiler on FreeBSD
for quite some time to come, I guess.

I'll see if I can manage to ring a few bells on the FreeBSD
mailinglist about this issue.

Rob.

Re: View-Postscript error: use --swap instead of -swap

[Rob Lahaye]

Rob Lahaye wrote:

 My LyX, by default, uses for Postscript viewing gv -swap
 (as in Tools-Preferences-Conversion-Formats, Postscript)

 However, eversince I upgraded to gv version 3.6.1, the -swap does
 not work anymore, and consequently, Postscript viewing with LyX is
 not working (not working with out-of-the box configuration, that is).

 I have to modify -swap to --swap in the preferences settings.
 Then it's OK again.

 Has nobody else with up-to-date gv, trouble with this?

 I wonder, whether LyX-CVS by default, should choose to support latest
 gv version. People with older gv, can then modify the preferences, or
 upgrade to newer gv.
 By the time the next LyX is released, it may not work with common version
 of gv of that time, maybe.

This could be a possible patch for fixing this for gv:

Index: lib/configure.m4
===
RCS file: /cvs/lyx/lyx-devel/lib/configure.m4,v
retrieving revision 1.91
diff -u -r1.91 configure.m4
--- lib/configure.m42005/01/20 15:02:15 1.91
+++ lib/configure.m42005/01/24 17:44:33
@@ -295,7 +295,8 @@
 # Search something to preview postscript
 SEARCH_PROG([for a Postscript previewer],GHOSTVIEW,gsview32 gv ghostview
kghostview)
 case $GHOSTVIEW in
-  gv|ghostview) PS_VIEWER=$GHOSTVIEW -swap ;;
+  gv) PS_VIEWER=$GHOSTVIEW --swap ;;
+  ghostview) PS_VIEWER=$GHOSTVIEW -swap ;;
   *) PS_VIEWER=$GHOSTVIEW;;
 esac
 EPS_VIEWER=$GHOSTVIEW

Re: FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
>>>>>>"Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
>
>
> Rob> I can compile LyX almost; something goes wrong at the very end.
> Rob> At the end of gmake, when the final executable is being linked, I
> Rob> get zillions of following lines:
>
> Rob> $ gmake [...]
> Rob>
BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE9_M_insertENS_14_List_iteratorIS1_EERKS1_+0x19):
> Rob> In function `__gnu_norm::list
>
>>>::_M_insert(__gnu_norm::_List_iterator, Branch const&)':
>
>
> Do you have one of these things defined in config.h?
>
> /* libstdc++ concept checking */
> #undef _GLIBCPP_CONCEPT_CHECKS
>
> /* libstdc++ concept checking */
> #undef _GLIBCXX_CONCEPT_CHECKS
>
> /* libstdc++ debug mode */
> #undef _GLIBCXX_DEBUG
>
> /* libstdc++ pedantic debug mode */
> #undef _GLIBCXX_DEBUG_PEDANTIC
>
> Could you test what happens when turning them off?

Yep, that solves the problem; not that I know what I'm doing though.
But LyX compiles like a charm!

Can you explain a little? Is this a bug, or a misbehaving feature
of FreeBSD, or perhaps LyX or gcc?

Even more important: how can I tell the configure script to never
set these #def directives again in the future?

Thanks!
Rob.

New Userdir: [Create directory] and [Exit LyX] buttons mixed up?

[Rob Lahaye]

Hi,

I start LyX-cvs like this:

 $ src/lyx -userdir /tmp/LyX

Because /tmp/LyX does not exist, a dialog appears with

  You have specified a non-existent user LyX
 directory, /tmp/LyX.
  It is needed to keep your own configuration.
  [Create directory][Exit LyX]

I then click on [Create directory], but LyX seems to just
exit without any message. The directory is not created.

HOWEVER, if I click on [Exit LyX], then LyX creates the
directory and continues.

Apparently the function of the two buttons are mixed up here.

Rob.

Re: FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
>>>>>> Rob Lahaye writes:
>
> Rob> Yep, that solves the problem; not that I know what I'm doing
> Rob> though. But LyX compiles like a charm!
>
> Rob> Can you explain a little? Is this a bug, or a misbehaving feature
> Rob> of FreeBSD, or perhaps LyX or gcc?
>
> I think this is a bug of gcc on freebsd. These things turn on some
> recent (gcc 3.3 or 3.4) debug features of the C++ standard library.
>
> It seems that at least one of these is broken. If you have time, you
> could try to turn them off one by one and see which one is the
> culprit.

It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC.


> Rob> Even more important: how can I tell the configure script to never
> Rob> set these #def directives again in the future?
>
> use --disable-stdlib-debug and/or --disable-concept-checks.

Using --disable-stdlib-debug is enough to solve the problem.


Does that make sense?

Rob.

View->Postscript error: use --swap instead of -swap

[Rob Lahaye]

Hi,

My LyX, by default, uses for Postscript viewing "gv -swap"
(as in Tools->Preferences->Conversion->Formats, Postscript)

However, eversince I upgraded to gv version 3.6.1, the -swap does
not work anymore, and consequently, Postscript viewing with LyX is
not working (not working with out-of-the box configuration, that is).

I have to modify -swap to --swap in the preferences settings.
Then it's OK again.

Has nobody else with up-to-date gv, trouble with this?

I wonder, whether LyX-CVS by default, should choose to support latest
gv version. People with older gv, can then modify the preferences, or
upgrade to newer gv.
By the time the next LyX is released, it may not work with common version
of gv of that time, maybe.

Rob.

Re: FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
> Rob> It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC.
>
> Rob> Does that make sense?
>
> So the stdlibc++ debug feature is broken with your compiler version, I
> guess. You should ask the freebsd people for more info. When we know
> exactly what happens, we can maybe blacklist some freebsd/gcc combo in
> the code that enables debug.
>
> What is your gcc version?

It's 3.4.2.
This version ships with FreeBSD 5.3 (latest release).
This version of gcc may be the default compiler on FreeBSD
for quite some time to come, I guess.

I'll see if I can manage to ring a few bells on the FreeBSD
mailinglist about this issue.

Rob.

Re: View->Postscript error: use --swap instead of -swap

[Rob Lahaye]

Rob Lahaye wrote:
>
> My LyX, by default, uses for Postscript viewing "gv -swap"
> (as in Tools->Preferences->Conversion->Formats, Postscript)
>
> However, eversince I upgraded to gv version 3.6.1, the -swap does
> not work anymore, and consequently, Postscript viewing with LyX is
> not working (not working with out-of-the box configuration, that is).
>
> I have to modify -swap to --swap in the preferences settings.
> Then it's OK again.
>
> Has nobody else with up-to-date gv, trouble with this?
>
> I wonder, whether LyX-CVS by default, should choose to support latest
> gv version. People with older gv, can then modify the preferences, or
> upgrade to newer gv.
> By the time the next LyX is released, it may not work with common version
> of gv of that time, maybe.

This could be a possible patch for fixing this for gv:

Index: lib/configure.m4
===
RCS file: /cvs/lyx/lyx-devel/lib/configure.m4,v
retrieving revision 1.91
diff -u -r1.91 configure.m4
--- lib/configure.m42005/01/20 15:02:15 1.91
+++ lib/configure.m42005/01/24 17:44:33
@@ -295,7 +295,8 @@
 # Search something to preview postscript
 SEARCH_PROG([for a Postscript previewer],GHOSTVIEW,gsview32 gv ghostview
kghostview)
 case $GHOSTVIEW in
-  gv|ghostview) PS_VIEWER="$GHOSTVIEW -swap" ;;
+  gv) PS_VIEWER="$GHOSTVIEW --swap" ;;
+  ghostview) PS_VIEWER="$GHOSTVIEW -swap" ;;
   *) PS_VIEWER="$GHOSTVIEW";;
 esac
 EPS_VIEWER=$GHOSTVIEW

FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Hi,

First: thanks for solving the sh vs. bash issue, which is now working
on my FreeBSD system.

I can compile LyX almost; something goes wrong at the very end.
At the end of gmake, when the final executable is being linked,
I get zillions of following lines:

$ gmake
[...]
BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE9_M_insertENS_14_List_iteratorIS1_EERKS1_+0x19):
In function `__gnu_norm::listBranch, std::allocatorBranch
::_M_insert(__gnu_norm::_List_iteratorBranch, Branch const)':

/usr/include/c++/3.4/bits/locale_facets.tcc:2443: undefined reference to
`__gnu_norm::_List_node_base::hook(__gnu_norm::_List_node_base*)'
BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE8_M_eraseENS_14_List_iteratorIS1_EE+0xd):
In function `__gnu_norm::listBranch, std::allocatorBranch
::_M_erase(__gnu_norm::_List_iteratorBranch)':

/usr/include/c++/3.4/debug/list:122: undefined reference to
`__gnu_norm::_List_node_base::unhook()'

[...cut...]

/usr/include/c++/3.4/bits/stl_algobase.h:155: undefined reference to
`__gnu_norm::_List_node_base::transfer(__gnu_norm::_List_node_base*,
__gnu_norm::_List_node_base*)'
../boost/libs/signals/src/.libs/libboost_signals.a(trackable.o)(.gnu.linkonce.t._ZN10__gnu_norm4listIN5boost7signals10connectionESaIS3_EE9_M_insertENS_14_List_iteratorIS3_EERKS3_+0x28):


In function `__gnu_norm::listboost::signals::connection,
std::allocatorboost::signals::connection
::_M_insert(__gnu_norm::_List_iteratorboost::signals::connection,
boost::signals::connection const)':

/usr/include/c++/3.4/debug/formatter.h:359: undefined reference to
`__gnu_norm::_List_node_base::hook(__gnu_norm::_List_node_base*)'
gmake[3]: *** [lyx-xforms] Error 1


All lines have something about __gnu_norm. Any idea what this is about?

I only have this with LyX, but if lyx-devel people tell me that this not a
LyX issue, I may next contact the FreeBSD list for answers.

Rob.

FreeBSD/gcc-3.4.2: gmake ends with linking error

[Rob Lahaye]

Hi,

First: thanks for solving the sh vs. bash issue, which is now working
on my FreeBSD system.

I can compile LyX almost; something goes wrong at the very end.
At the end of gmake, when the final executable is being linked,
I get zillions of following lines:

$ gmake
[...]
BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE9_M_insertENS_14_List_iteratorIS1_EERKS1_+0x19):
In function `__gnu_norm::list::_M_insert(__gnu_norm::_List_iterator, Branch const&)':

/usr/include/c++/3.4/bits/locale_facets.tcc:2443: undefined reference to
`__gnu_norm::_List_node_base::hook(__gnu_norm::_List_node_base*)'
BranchList.o(.gnu.linkonce.t._ZN10__gnu_norm4listI6BranchSaIS1_EE8_M_eraseENS_14_List_iteratorIS1_EE+0xd):
In function `__gnu_norm::list::_M_erase(__gnu_norm::_List_iterator)':

/usr/include/c++/3.4/debug/list:122: undefined reference to
`__gnu_norm::_List_node_base::unhook()'

[...cut...]

/usr/include/c++/3.4/bits/stl_algobase.h:155: undefined reference to
`__gnu_norm::_List_node_base::transfer(__gnu_norm::_List_node_base*,
__gnu_norm::_List_node_base*)'
../boost/libs/signals/src/.libs/libboost_signals.a(trackable.o)(.gnu.linkonce.t._ZN10__gnu_norm4listIN5boost7signals10connectionESaIS3_EE9_M_insertENS_14_List_iteratorIS3_EERKS3_+0x28):


In function `__gnu_norm::list::_M_insert(__gnu_norm::_List_iterator,
boost::signals::connection const&)':

/usr/include/c++/3.4/debug/formatter.h:359: undefined reference to
`__gnu_norm::_List_node_base::hook(__gnu_norm::_List_node_base*)'
gmake[3]: *** [lyx-xforms] Error 1


All lines have something about "__gnu_norm". Any idea what this is about?

I only have this with LyX, but if lyx-devel people tell me that this not a
LyX issue, I may next contact the FreeBSD list for answers.

Rob.

boost/libs/filesystem/src: Syntax error: Bad substitution

[Rob Lahaye]

On FreeBSD 5.3, with GCC-3.4.2:

[...]
gmake[4]: Entering directory
`/home/lahaye/SOFTWARE/lyx-devel/boost/libs/filesystem/src'
TMPCMD=` echo g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src  -Winvalid-pch
--include=./pch.h -DBOOST_USER_CONFIG=config.h -I../../../../boost -Wextra
-Wall -I/usr/local/include   -I/usr/X11R6/include  -g -O -fno-exceptions | sed
-e s,\,\',` ; \
PATTERN=`echo -Winvalid-pch --include=./pch.h | sed -e 's,\/,\\\/,'` ; \
${TMPCMD/$PATTERN} \
-x c++-header ./pch.h -MT pch.h.gch -MD -MP -MF ./pch.h.gch.Tdep \
 mv ./pch.h.gch.Tdep ./pch.h.gch.dep || rm ./pch.h.gch.Tdep
Syntax error: Bad substitution
gmake[4]: *** [pch.h.gch] Error 2


What's the Syntax error: Bad substitution here?

Rob.

Re: boost/libs/filesystem/src: Syntax error: Bad substitution

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
 Rob Lahaye [EMAIL PROTECTED] writes:

 | On FreeBSD 5.3, with GCC-3.4.2:

 | [...]
 | gmake[4]: Entering directory
 | `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/filesystem/src'
 | TMPCMD=` echo g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src  -Winvalid-pch
 | --include=./pch.h -DBOOST_USER_CONFIG=config.h -I../../../../boost
-Wextra
 | -Wall -I/usr/local/include   -I/usr/X11R6/include  -g -O -fno-exceptions |
sed
 | -e s,\,\',` ; \
 | PATTERN=`echo -Winvalid-pch --include=./pch.h | sed -e 's,\/,\\\/,'` ; \
 | ${TMPCMD/$PATTERN} \
 | -x c++-header ./pch.h -MT pch.h.gch -MD -MP -MF ./pch.h.gch.Tdep \
 |  mv ./pch.h.gch.Tdep ./pch.h.gch.dep || rm ./pch.h.gch.Tdep
 | Syntax error: Bad substitution
 | gmake[4]: *** [pch.h.gch] Error 2


 | What's the Syntax error: Bad substitution here?

 not bash?


Hmm, bash is the default shell in the linux community, isn't it?
However, the FreeBSD base system has csh, sh and tcsh.
Of course, I can install bash as an additional package, but is it
wise to make these build scripts depend on a kind of 'linux-ism'?

Regards,
Rob.

Re: boost/libs/filesystem/src: Syntax error: Bad substitution

[Rob Lahaye]

Jose' Matos wrote:
 On Tuesday 18 January 2005 12:12, Rob Lahaye wrote:

not bash?

Hmm, bash is the default shell in the linux community, isn't it?
However, the FreeBSD base system has csh, sh and tcsh.

   We should make it work with sh, as it will then work in other posix
 systems, if that is what you mean. :-)

Yes, indeed, that is exactly what I mean. I believe 'sh' is garanteed
to be included in any flavor of *nix, the free and commercial ones.

Thank you for rephrasing it more correctly.

Rob.

boost/libs/filesystem/src: Syntax error: Bad substitution

[Rob Lahaye]

On FreeBSD 5.3, with GCC-3.4.2:

[...]
gmake[4]: Entering directory
`/home/lahaye/SOFTWARE/lyx-devel/boost/libs/filesystem/src'
TMPCMD=` echo g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src  -Winvalid-pch
--include=./pch.h -DBOOST_USER_CONFIG="" -I../../../../boost -Wextra
-Wall -I/usr/local/include   -I/usr/X11R6/include  -g -O -fno-exceptions | sed
-e s,\",\',` ; \
PATTERN=`echo -Winvalid-pch --include=./pch.h | sed -e 's,\/,\\\/,'` ; \
${TMPCMD/$PATTERN} \
-x c++-header ./pch.h -MT pch.h.gch -MD -MP -MF "./pch.h.gch.Tdep" \
&& mv "./pch.h.gch.Tdep" "./pch.h.gch.dep" || rm "./pch.h.gch.Tdep"
Syntax error: Bad substitution
gmake[4]: *** [pch.h.gch] Error 2


What's the "Syntax error: Bad substitution" here?

Rob.

Re: boost/libs/filesystem/src: Syntax error: Bad substitution

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>
> | On FreeBSD 5.3, with GCC-3.4.2:
>
> | [...]
> | gmake[4]: Entering directory
> | `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/filesystem/src'
> | TMPCMD=` echo g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src  -Winvalid-pch
> | --include=./pch.h -DBOOST_USER_CONFIG="" -I../../../../boost
-Wextra
> | -Wall -I/usr/local/include   -I/usr/X11R6/include  -g -O -fno-exceptions |
sed
> | -e s,\",\',` ; \
> | PATTERN=`echo -Winvalid-pch --include=./pch.h | sed -e 's,\/,\\\/,'` ; \
> | ${TMPCMD/$PATTERN} \
> | -x c++-header ./pch.h -MT pch.h.gch -MD -MP -MF "./pch.h.gch.Tdep" \
> | && mv "./pch.h.gch.Tdep" "./pch.h.gch.dep" || rm "./pch.h.gch.Tdep"
> | Syntax error: Bad substitution
> | gmake[4]: *** [pch.h.gch] Error 2
>
>>
> | What's the "Syntax error: Bad substitution" here?
>
> not bash?
>

Hmm, bash is the default shell in the linux community, isn't it?
However, the FreeBSD base system has csh, sh and tcsh.
Of course, I can install bash as an additional package, but is it
wise to make these build scripts depend on a kind of 'linux-ism'?

Regards,
Rob.

Re: boost/libs/filesystem/src: Syntax error: Bad substitution

[Rob Lahaye]

Jose' Matos wrote:
> On Tuesday 18 January 2005 12:12, Rob Lahaye wrote:
>
>>>not bash?
>>
>>Hmm, bash is the default shell in the linux community, isn't it?
>>However, the FreeBSD base system has csh, sh and tcsh.
>
>   We should make it work with sh, as it will then work in other posix
> systems, if that is what you mean. :-)

Yes, indeed, that is exactly what I mean. I believe 'sh' is garanteed
to be included in any flavor of *nix, the free and commercial ones.

Thank you for rephrasing it more correctly.

Rob.

Re: FreeBSD compilation problems with boost stuff

[Rob Lahaye]

Lars Gullik Bjønnes wrote:

 Rob [EMAIL PROTECTED] writes:

 | Hi,

 | There are few clashes with LyX's boost stuff on the FreeBSD system.
 | I use compiler gcc 3.4.2.

 | 1. Following patch is needed to have cstdint.hpp compile without
 |error message (I have tried to investigate where exactly uintmax_t
 |is already defined on my system, but to no avail; I've already
 |reported this some time ago).

 Can you report it to the boost list as well?
 (your fix might be our breakage)

 | 2. After above patch, I now get following problems:

 | /usr/local/bin/g++34 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost
 | -I/opt/include -I/usr/local/include -I/usr/X11R6/include -Winvalid-pch
 | --include=./pch.h
 | -g -O -fno-exceptions -Wextra -Wall -c tostr.C -MT tostr.lo -MD -MP -MF
 | .deps/tostr.TPlo -o tostr.o
 | In file included from tostr.C:14:
 | ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a
 | member of `std'

 Hmm we define BOOST_NO_WSTRING in config.h so there should be no
 way for you to get the wstring stuff at all. What gives?
 Ok I see... there is a template3 specialization in lexical_cast that
 is not protected by DISABLE_WIDE_CHAR_SUPPORT.

 I'll send a msg to the boost list about this one.


Meanwhile I have communicated this to the boost list and got following
two answers:

-

1)
 Could be related to the following g++ problem. Scheduled to be
 fixed in gcc 3.5
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005

2)
 FreeBSD's wchar_t support is limited, so GCC does not enable any
 wide-char support in the C++ stdlib

 All uses of wstring/char_t/wstream etc. are be guarded by
 BOOST_NO_WSTRING so they aren't compiled on platforms without wchar
 support in the stdlib. BOOST_NO_WSTRING will get set automatically
 because the stdlib does not define _GLIBCXX_USE_WCHAR_T on FreeBSD.

 However, Boost 1.31 was released before GCC 3.4.1, which changed the
 stdlib macros from _GLIBCPP_blahblah to _GLIBCXX_blahblah and so Boost's
 config fails to configure correctly for this compiler. You could try
 taking the boost/config/stdlib/libstdcppv3.hpp header from CVS, but note
 that there are additional problems with GCC 3.4.x and Boost due to GCC
 3.4 unconditionally defining _REENTRANT. See GCC PR 11953 for details.
 (I've written a summary of this issue, but it's sitting on my hard drive
 at home somewhere. I need to send it to this list...)

 In short, you must define either BOOST_DISABLE_THREADS or compile with
 -pthreads to avoid linker errors from the pthread_xxx functions.

-

Does that give a clue to you LyX/Boost gurus?

Or will it be for FreeBSD just a matter of waiting for 3.5 to be released?
Unfortunately, the soon upcoming release branch 5.X of FreeBSD ships with
GCC 3.4.2. So the problem may persist for quite some time.

Rob.

Re: FreeBSD compilation problems with boost stuff

[Rob Lahaye]

Lars Gullik Bjønnes wrote:

> Rob <[EMAIL PROTECTED]> writes:
>
> | Hi,
>
> | There are few clashes with LyX's boost stuff on the FreeBSD system.
> | I use compiler gcc 3.4.2.
>
> | 1. Following patch is needed to have cstdint.hpp compile without
> |error message (I have tried to investigate where exactly uintmax_t
> |is already defined on my system, but to no avail; I've already
> |reported this some time ago).
>
> Can you report it to the boost list as well?
> (your fix might be our breakage)
>
> | 2. After above patch, I now get following problems:
>
> | /usr/local/bin/g++34 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost
> | -I/opt/include -I/usr/local/include -I/usr/X11R6/include -Winvalid-pch
> | --include=./pch.h
> | -g -O -fno-exceptions -Wextra -Wall -c tostr.C -MT tostr.lo -MD -MP -MF
> | .deps/tostr.TPlo -o tostr.o
> | In file included from tostr.C:14:
> | ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a
> | member of `std'
>
> Hmm we define BOOST_NO_WSTRING in config.h so there should be no
> way for you to get the "wstring" stuff at all. What gives?
> Ok I see... there is a template3 specialization in lexical_cast that
> is not protected by DISABLE_WIDE_CHAR_SUPPORT.
>
> I'll send a msg to the boost list about this one.


Meanwhile I have communicated this to the boost list and got following
two answers:

-

1)
 Could be related to the following g++ problem. Scheduled to be
 fixed in gcc 3.5
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005

2)
 FreeBSD's wchar_t support is limited, so GCC does not enable any
 wide-char support in the C++ stdlib

 All uses of wstring/char_t/wstream etc. are be guarded by
 BOOST_NO_WSTRING so they aren't compiled on platforms without wchar
 support in the stdlib. BOOST_NO_WSTRING will get set automatically
 because the stdlib does not define _GLIBCXX_USE_WCHAR_T on FreeBSD.

 However, Boost 1.31 was released before GCC 3.4.1, which changed the
 stdlib macros from _GLIBCPP_blahblah to _GLIBCXX_blahblah and so Boost's
 config fails to configure correctly for this compiler. You could try
 taking the boost/config/stdlib/libstdcppv3.hpp header from CVS, but note
 that there are additional problems with GCC 3.4.x and Boost due to GCC
 3.4 unconditionally defining _REENTRANT. See GCC PR 11953 for details.
 (I've written a summary of this issue, but it's sitting on my hard drive
 at home somewhere. I need to send it to this list...)

 In short, you must define either BOOST_DISABLE_THREADS or compile with
 -pthreads to avoid linker errors from the pthread_xxx functions.

-

Does that give a clue to you LyX/Boost gurus?

Or will it be for FreeBSD just a matter of waiting for 3.5 to be released?
Unfortunately, the soon upcoming release branch 5.X of FreeBSD ships with
GCC 3.4.2. So the problem may persist for quite some time.

Rob.

Re: Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

Andre Poenitz wrote:
On Thu, Jun 03, 2004 at 07:37:00PM +0900, Rob Lahaye wrote:
I'm suprised nobody is upset about this!?!
Using a provider with a good spam filter helps a lot.
Bleh! This is about preventing spam, not how to filter it
PS: I wish I could use my anti-spam email address for this, but lyx
doesn't allow me.  My 'anti-spam' email address bounces back, since
it's fake; ...

This is considered rude behaviour in some parts of the net...
Rude? When communicating with a public mailing list?
The mailinglist should be the medium of communication, not the personal
email addresses. And in this context I'd rather be a little rude and
prevent spamming, than also being polite to spammers
Ah, well, I made my point. If noone else cares, then let it be.
Cheers,
Rob.

Re: Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

Andre Poenitz wrote:
On Thu, Jun 03, 2004 at 07:37:00PM +0900, Rob Lahaye wrote:
I'm suprised nobody is upset about this!?!
Using a provider with a good spam filter helps a lot.
Bleh! This is about preventing spam, not how to filter it
PS: I wish I could use my anti-spam email address for this, but lyx
doesn't allow me.  My 'anti-spam' email address bounces back, since
it's fake; ...

This is considered rude behaviour in some parts of the net...
Rude? When communicating with a public mailing list?
The mailinglist should be the medium of communication, not the personal
email addresses. And in this context I'd rather be a little rude and
prevent spamming, than also being polite to spammers
Ah, well, I made my point. If noone else cares, then let it be.
Cheers,
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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;
| 2) When I keep the offending typedef line in boost/boost/cstdint.hpp
| and comment out in  /usr/include/inttypes.h  this line:
| //typedef   __uint64_t  uint64_t;
| I get another (obvious?) error during the compilation:
| [...snip...]
| depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
| /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
|   /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -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:116: error: `uint64_t' not
| declared
So commenting out the line in inttypes.h is not the solution.
| What else can I do, to clarify this problem?
Is __uint64_t a typedef? Or a macro?
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 */
  typedef long long__int64_t;
  /* LONGLONG */
  typedef unsigned long long  __uint64_t;
  #endif
There are many other typedefs here (without the #ifdef construct), for example:
  typedef __signed char  __int8_t;
  typedef unsigned char __uint8_t;
  typedef short __int16_t;
  typedef unsigned short   __uint16_t;
  typedef int   __int32_t;
  typedef unsigned int __uint32_t;
  typedef int  __intptr_t;
  typedef unsigned int__uintptr_t;
Does that ring a bell?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

| 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
$ cat test.C
#include boost/cstdint.hpp
int main() { return 0; }
$ g++33 -W -Wall -Iboost -c -o test.o test.C
$
Apparently, no problem!
I hope that gives a hint, does it?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 -Iboost -c
-o test.o test.C

| $ cd lyx-top dir
| $ cat test.C
| #include boost/cstdint.hpp
| int main() { return 0; }
| $ g++33 -W -Wall -Iboost -c -o test.o test.C
| $

| Apparently, no problem!

| I hope that gives a hint, does it?
Yes it might... can you give me the origianl failure report again.
(sorry for making you do the leg work...)
No, not at all. I'm glad you're giving me clear directions, since I have
no idea how to proceed. So, here you go:
source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \
depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/opt/include  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
 /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost -I/opt/include 
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -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: error: redeclaration of C++ built-in
   type `long'
Just to clearify, is this on a 32bit or 64bit platform?
CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2612.57-MHz 686-class CPU)
That's 32 bit, right?
Rob.

Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

Hi,
[EMAIL PROTECTED]   mailing list needs subscription (or alternatively
a once-only permission granted for sending emails, without the full
subscription). Once that is done, all emails to the list are also archived
at
 1) www.mail-archive.com/[EMAIL PROTECTED]
 2) marc.theaimsgroup.com/?l=lyx-devel
 3) gmane.org
  (are there more?)
All these archives are publicly available, which means someone can collect
the emails from there for third parties spam-junk stuff, if the sender's
email address is not hidden; mail-archive and theaimsgroup do this nicely!
But here is, I believe, where the trouble with gmane.org starts: all emails
are 'as-is' on this archive, nothing is hidden! Which means, it's an
excellent source for spam/junk distibutors to add all lyx-devel contributors
to their list of email addresses.
So, the carefullness by the subscription mechanism and the mail-archive/theaimsgroup
hiding strategy, is made totally redundant by forwarding everything automatically
also to the gmane.org.
Actually, by forcing the use of a legitimate email address by the subscription
mechanism, we are also forced to have our legitimate email address published on the
public gmane archive. This is a very bad construction!
Any opinions?
Regards,
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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
#  include stdexcept
#  include iterator
#  include iosfwd
#  include vector
#  include boost/config.hpp
#  include boost/cstdint.hpp
int main() {return 0; }
$
Again, no problem. What else can I do?
Rob.

Re: Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

Lars Gullik Bjønnes:
Rob Lahaye [EMAIL PROTECTED] writes:
| Hi,

| [EMAIL PROTECTED]   mailing list needs subscription (or alternatively
| a once-only permission granted for sending emails, without the full
| subscription). Once that is done, all emails to the list are also archived
| at
|   1) www.mail-archive.com/[EMAIL PROTECTED]
|   2) marc.theaimsgroup.com/?l=lyx-devel
|   3) gmane.org

|(are there more?)

| All these archives are publicly available, which means someone can collect
| the emails from there for third parties spam-junk stuff, if the sender's
| email address is not hidden; mail-archive and theaimsgroup do this nicely!
| But here is, I believe, where the trouble with gmane.org starts: all emails
| are 'as-is' on this archive, nothing is hidden! Which means, it's an
| excellent source for spam/junk distibutors to add all lyx-devel contributors
| to their list of email addresses.

| So, the carefullness by the subscription mechanism and the mail-archive/theaimsgroup
| hiding strategy, is made totally redundant by forwarding everything automatically
| also to the gmane.org.
| Actually, by forcing the use of a legitimate email address by the subscription
| mechanism, we are also forced to have our legitimate email address published on the
| public gmane archive. This is a very bad construction!

| Any opinions?
IMHO as it should be.
That is: you want people to use a legitimate email address (with the subscription
mechanism), and then silently put the full email address on a public archive. Not
very nice at all!
Especially, many people may think that the subscription protects against abuse by
others (it usually does), but the very same people may not even be aware of the
fact that lyx makes their email address available to everyone on gmane.org!!!
If I was a malicious spam distributor, I would grap a nice collection of legitimate
email addresses from gmane; the lyx list in particular is useful, because there all
are legitimate email addresses
I'm suprised nobody is upset about this!?!
Regards,
Rob.
PS: I wish I could use my anti-spam email address for this, but lyx doesn't allow me.
My 'anti-spam' email address bounces back, since it's fake; so all communication
should then go via the mailing list and not to me personally.
For example, you can find me on the FreeBSD mailing lists (also archived on gmane.org),
but only with my anti-spam email address!

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 main() { return 0; }
$
And still, LyX gets stuck in boost on my FreeBSD PC.
Problem is, that I can't make head nor tail from the complex coding
in that boost stuff. I can't even make much out of the error message
(well, Lars helped me out here, but it's still foggy stuff for me).
Any other suggestions.?
Ah well, if nobody else suffers from this, as of yet!?!
Regards,
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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:
OK, got something here.
I copied (more or less) the compile line as it appears in the gmake
process. And then I found that the following fails:
$ cat test.C
#include boost/regex/config.hpp
int main() { return 0; }
$ 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 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 that ring a bell?
Do you need to know what I have in src/config.h ?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Angus Leeming:
So what happens if you #include *all* the system 
headers of cpp_regex_traits.cpp
$ cat test.C
#include boost/regex/config.hpp
#include clocale
#include locale
#include cstdio
#include list
#include cctype
#include iostream
#include map
#include boost/regex/regex_traits.hpp
#include boost/cregex.hpp
#include boost/scoped_array.hpp
int main() { return 0; }
$ 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 boost/boost/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 ENABLE_NLS 1
#define HAVE_ALLOCA 1
#define HAVE_ASPELL_H 1
#define HAVE_ASPRINTF 1
#define HAVE_DCGETTEXT 1
#define HAVE_DECL_FEOF_UNLOCKED 1
#define HAVE_DECL_FGETS_UNLOCKED 0
#define HAVE_DECL_GETC_UNLOCKED 1
#define HAVE_DECL_ISTREAMBUF_ITERATOR 1
#define HAVE_DECL_MKSTEMP 1
#define HAVE_DECL_SNPRINTF 1
#define HAVE_DECL_VSNPRINTF 1
#define HAVE_DECL__SNPRINTF 0
#define HAVE_DECL__SNWPRINTF 0
#define HAVE_DIRENT_H 1
#define HAVE_DLFCN_H 1
#define HAVE_GETCWD 1
#define HAVE_GETEGID 1
#define HAVE_GETEUID 1
#define HAVE_GETGID 1
#define HAVE_GETPAGESIZE 1
#define HAVE_GETTEXT 1
#define HAVE_GETUID 1
#define HAVE_ICONV 1
#define HAVE_INTTYPES_H 1
#define HAVE_IOS 1
#define HAVE_ISTREAM 1
#define HAVE_KPSEWHICH 1
#define HAVE_LANGINFO_CODESET 1
#define HAVE_LC_MESSAGES 1
#define HAVE_LIBC 1
#define HAVE_LIBM 1
#define HAVE_LIMITS 1
#define HAVE_LIMITS_H 1
#define HAVE_LOCALE 1
#define HAVE_LOCALE_H 1
#define HAVE_LONG_DOUBLE 1
#define HAVE_LONG_LONG 1
#define HAVE_MALLOC_H 1
#define HAVE_MEMMOVE 1
#define HAVE_MEMORY_H 1
#define HAVE_MEMSET 1
#define HAVE_MKFIFO 1
#define HAVE_MKSTEMP 1
#define HAVE_MKTEMP 1
#define HAVE_MMAP 1
#define HAVE_MUNMAP 1
#define HAVE_NL_TYPES_H 1
#define HAVE_OSTREAM 1
#define HAVE_POSIX_PRINTF 1
#define HAVE_PUTENV 1
#define HAVE_SETENV 1
#define HAVE_SETLOCALE 1
#define HAVE_SNPRINTF 1
#define HAVE_SSTREAM 1
#define HAVE_STDDEF_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STD_COUNT 1
#define HAVE_STRCASECMP 1
#define HAVE_STRCHR 1
#define HAVE_STRDUP 1
#define HAVE_STRERROR 1
#define HAVE_STRINGS_H 1
#define HAVE_STRING_H 1
#define HAVE_STRTOUL 1
#define HAVE_SYS_PARAM_H 1
#define HAVE_SYS_SELECT_H 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_TSEARCH 1
#define HAVE_UNISTD_H 1
#define HAVE_UNSIGNED_LONG_LONG 1
#define HAVE_VSNPRINTF 1
#define HAVE_WCHAR_T 1
#define HAVE_WCSLEN 1
#define HAVE_WINT_T 1
#define HAVE_X11_FLIMAGE_H 1
#define HAVE_ZLIB_H 1
#define ICONV_CONST const
#define INTDIV0_RAISES_SIGFPE 1
#define MODERN_STL_STREAMS 1
#define PACKAGE lyx
#define PACKAGE_BUGREPORT [EMAIL PROTECTED]
#define PACKAGE_NAME lyx
#define PACKAGE_STRING lyx 1.4.0cvs
#define PACKAGE_TARNAME lyx
#define PACKAGE_VERSION 1.4.0cvs
#define RETSIGTYPE void
#define SELECT_TYPE_ARG1 int
#define SELECT_TYPE_ARG234 (fd_set *)
#define SELECT_TYPE_ARG5 (struct timeval *)
#define SIZE_MAX 4294967295U
#define STDC_HEADERS 1
#define TIME_WITH_SYS_TIME 1
#define USE_ASPELL 1
#define USE_COMRESSION 1
#define USE_JPEG_IMAGE_LOADER 1
#define VERSION 1.4.0cvs
#define WITH_WARNINGS 1
#ifndef _ALL_SOURCE
#endif
#define uintmax_t unsigned long long
#ifndef HAVE_STRCHR
# define strchr(a,b)index(a,b)
#endif
#ifndef HAVE_MEMMOVE
# define memmove(a,b,c) bcopy(b,a,c)
#endif
#ifndef HAVE_STRERROR
#if defined(__cplusplus)
#endif
#endif
#ifdef BROKEN_HEADERS
#include broken_headers.h
#endif
#ifdef HAVE_MKSTEMP
#ifndef HAVE_DECL_MKSTEMP
#if defined(__cplusplus)
#endif
#endif
#endif
#ifdef __EMX__
#include support/os2_defines.h
#endif
#if defined(HAVE_OSTREAM)  defined(HAVE_LOCALE)  defined(HAVE_SSTREAM)
#define USE_BOOST_FORMAT 1
#else
#define USE_BOOST_FORMAT 0
#endif
#define BOOST_USER_CONFIG config.h
#if defined(ENABLE_ASSERTIONS)
#define BOOST_ENABLE_ASSERT_HANDLER 1
#else
#define BOOST_DISABLE_ASSERTS 1
#endif
#define BOOST_DISABLE_THREADS 1
#define BOOST_NO_WREGEX 1
#define BOOST_NO_WSTRING 1
#endif

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Angus Leeming wrote:
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++?
$ cat test.C
#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 -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'
Once again: removing   -DBOOST_USER_CONFIG=config.h  from the compile
line above, solves the problem.
Does that bring us any closer?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 is screwing things up.
As a preliminary guess, looking at the config.h you posted, try
#define uintmax_t unsigned long long
#include boost/cstdint.hpp
int main () { return 0; }
Compile with a normal
$ gcc -Ipath to lyx/boost -o trial trial.C
Anyway, I'm sure that you get the point and can find the offender
from here.
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?
Actually, your suggestion to put another #define in the trial.C file,
is totally uncomprehesible for me :(. Don't see at all what it means.
Rob.

Re: Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

[EMAIL PROTECTED] wrote:
On Thu, Jun 03, 2004 at 05:46:16PM +0900, Rob Lahaye wrote:
All these archives are publicly available, which means someone can collect
the emails from there for third parties spam-junk stuff, if the sender's
email address is not hidden; mail-archive and theaimsgroup do this nicely!

theaimsgroup is the worst, if you want my opinion.  Within hours of posting
to a list there, the address I use gets spammed.  Tried it many times.

But here is, I believe, where the trouble with gmane.org starts: all emails
are 'as-is' on this archive, nothing is hidden! Which means, it's an
excellent source for spam/junk distibutors to add all lyx-devel contributors
to their list of email addresses.

There are many developers who read this list as news; they need gmane.  


So, the carefullness by the subscription mechanism and the 
mail-archive/theaimsgroup
hiding strategy, is made totally redundant by forwarding everything 
automatically
also to the gmane.org.
Actually, by forcing the use of a legitimate email address by the 
subscription
mechanism, we are also forced to have our legitimate email address 
published on the
public gmane archive. This is a very bad construction!


Can you back up your claim about gmane not hiding the aaddresses?  Have you
read
http://gmane.org/tmda.php
No I haven't. I find it rather complicated though.
What do you think of this excerpt:
   While the X-Archive header makes all addresses in your message be encrypted,
   if somebody on the mailing list responds to your message, it's still likely
   that your real email address will be included in the follow-up. It's probably
   more useful to switch encryption on for the entire list.
Encription of entire list!?! Sounds like that would solve the exposure of email
addresses for everyone, especially new subscribers; old subscribers are already
exposed until now :(.
Sorry, I'm not an email expert; don't know about setting X-archive fields etc.
I'm only worried about the increasing amount of spam arriving at my inbox (yes,
yes, I use a spam filter.).
Rob.
By the way: are you [EMAIL PROTECTED]? It's just there on gmane archive!

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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?
Actually, your suggestion to put another #define in the trial.C
file, is totally uncomprehesible for me :(. Don't see at all what it
means.

config.h is included from within boost/cstdint.hpp if you pass
-DBOOST_USER_CONFIG=config.h to the compiler.
So, rather than pass this macro to the compiler I was telling you
to compile this 'normally'. Ie without the macro.
#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 lines in src/config.h:
/* Define to unsigned long or unsigned long long if stdint.h and
   inttypes.h don't define. */
#define uintmax_t unsigned long long
which obviously causes the trouble. Apparently, this clashes with what
I have in /usr/include/machine/ansi.h:
typedef unsigned long long  __uint64_t;
Or another typedef elsewhere? Does this bring us any closer?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Angus Leeming wrote:
Sigh.
I'd like you to post a minimal, failing program of the form
#define uintmax_t unsigned long long
#include cstdint.hpp
int main() { return 0; }
where the #define is taken from your config.h file.
Right, you've got it already. So here we go again:
$ cat test.C
#define 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: error: redeclaration of C++ built-in type `long'
Is this enough, or am I supposed to provide more info?
Please bear with me; I'm still not so sure what I'm doingdon't know
anything about what is happening in the boost stuff, and why this all
of a sudden clashes with the config.h file.
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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;
| 2) When I keep the offending typedef line in boost/boost/cstdint.hpp
| and comment out in  /usr/include/inttypes.h  this line:
| //typedef   __uint64_t  uint64_t;
| I get another (obvious?) error during the compilation:
| [...snip...]
| depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
| /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
|   /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-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,
|   from cpp_regex_traits.cpp:22:
| ../../../../boost/boost/cstdint.hpp:116: error: `uint64_t' not
| declared
So commenting out the line in inttypes.h is not the solution.
| What else can I do, to clarify this problem?
Is __uint64_t a typedef? Or a macro?
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 */
  typedef long long__int64_t;
  /* LONGLONG */
  typedef unsigned long long  __uint64_t;
  #endif
There are many other typedefs here (without the #ifdef construct), for example:
  typedef __signed char  __int8_t;
  typedef unsigned char __uint8_t;
  typedef short __int16_t;
  typedef unsigned short   __uint16_t;
  typedef int   __int32_t;
  typedef unsigned int __uint32_t;
  typedef int  __intptr_t;
  typedef unsigned int__uintptr_t;
Does that ring a bell?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

| 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 main() { return 0; }
$ g++33 -W -Wall -Iboost -c -o test.o test.C
$
Apparently, no problem!
I hope that gives a hint, does it?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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++ -W -Wall -Iboost -c
-o test.o test.C

| $ cd 
| $ cat test.C
| #include 
| int main() { return 0; }
| $ g++33 -W -Wall -Iboost -c -o test.o test.C
| $

| Apparently, no problem!

| I hope that gives a hint, does it?
Yes it might... can you give me the origianl failure report again.
(sorry for making you do the leg work...)
No, not at all. I'm glad you're giving me clear directions, since I have
no idea how to proceed. So, here you go:
source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \
depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_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 -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
 /usr/local/bin/g++33 -DHAVE_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 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'
Just to clearify, is this on a 32bit or 64bit platform?
CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2612.57-MHz 686-class CPU)
That's 32 bit, right?
Rob.

Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

Hi,
[EMAIL PROTECTED]   mailing list needs subscription (or alternatively
a once-only permission granted for sending emails, without the full
subscription). Once that is done, all emails to the list are also archived
at
 1) www.mail-archive.com/[EMAIL PROTECTED]
 2) marc.theaimsgroup.com/?l=lyx-devel
 3) gmane.org
  (are there more?)
All these archives are publicly available, which means someone can collect
the emails from there for third parties spam-junk stuff, if the sender's
email address is not hidden; mail-archive and theaimsgroup do this nicely!
But here is, I believe, where the trouble with gmane.org starts: all emails
are 'as-is' on this archive, nothing is hidden! Which means, it's an
excellent source for spam/junk distibutors to add all lyx-devel contributors
to their list of email addresses.
So, the carefullness by the subscription mechanism and the mail-archive/theaimsgroup
hiding strategy, is made totally redundant by forwarding everything automatically
also to the gmane.org.
Actually, by forcing the use of a legitimate email address by the subscription
mechanism, we are also forced to have our legitimate email address published on the
public gmane archive. This is a very bad construction!
Any opinions?
Regards,
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 
#  include 
int main() {return 0; }
$
Again, no problem. What else can I do?
Rob.

Re: Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

Lars Gullik Bjønnes:
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Hi,

| [EMAIL PROTECTED]   mailing list needs subscription (or alternatively
| a once-only permission granted for sending emails, without the full
| subscription). Once that is done, all emails to the list are also archived
| at
|   1) www.mail-archive.com/[EMAIL PROTECTED]
|   2) marc.theaimsgroup.com/?l=lyx-devel
|   3) gmane.org

|(are there more?)

| All these archives are publicly available, which means someone can collect
| the emails from there for third parties spam-junk stuff, if the sender's
| email address is not hidden; mail-archive and theaimsgroup do this nicely!
| But here is, I believe, where the trouble with gmane.org starts: all emails
| are 'as-is' on this archive, nothing is hidden! Which means, it's an
| excellent source for spam/junk distibutors to add all lyx-devel contributors
| to their list of email addresses.

| So, the carefullness by the subscription mechanism and the mail-archive/theaimsgroup
| hiding strategy, is made totally redundant by forwarding everything automatically
| also to the gmane.org.
| Actually, by forcing the use of a legitimate email address by the subscription
| mechanism, we are also forced to have our legitimate email address published on the
| public gmane archive. This is a very bad construction!

| Any opinions?
IMHO as it should be.
That is: you want people to use a legitimate email address (with the subscription
mechanism), and then silently put the full email address on a public archive. Not
very nice at all!
Especially, many people may think that the subscription protects against abuse by
others (it usually does), but the very same people may not even be aware of the
fact that lyx makes their email address available to everyone on gmane.org!!!
If I was a malicious spam distributor, I would grap a nice collection of legitimate
email addresses from gmane; the lyx list in particular is useful, because there all
are legitimate email addresses
I'm suprised nobody is upset about this!?!
Regards,
Rob.
PS: I wish I could use my anti-spam email address for this, but lyx doesn't allow me.
My 'anti-spam' email address bounces back, since it's fake; so all communication
should then go via the mailing list and not to me personally.
For example, you can find me on the FreeBSD mailing lists (also archived on gmane.org),
but only with my anti-spam email address!

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 still, LyX gets stuck in boost on my FreeBSD PC.
Problem is, that I can't make head nor tail from the complex coding
in that boost stuff. I can't even make much out of the error message
(well, Lars helped me out here, but it's still foggy stuff for me).
Any other suggestions.?
Ah well, if nobody else suffers from this, as of yet!?!
Regards,
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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:
OK, got something here.
I copied (more or less) the compile line as it appears in the gmake
process. And then I found that the following fails:
$ cat test.C
#include 
int main() { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/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/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 bell?
Do you need to know what I have in src/config.h ?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Angus Leeming:
So what happens if you #include *all* the system 
headers of cpp_regex_traits.cpp
$ cat test.C
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
int main() { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/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/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 ENABLE_NLS 1
#define HAVE_ALLOCA 1
#define HAVE_ASPELL_H 1
#define HAVE_ASPRINTF 1
#define HAVE_DCGETTEXT 1
#define HAVE_DECL_FEOF_UNLOCKED 1
#define HAVE_DECL_FGETS_UNLOCKED 0
#define HAVE_DECL_GETC_UNLOCKED 1
#define HAVE_DECL_ISTREAMBUF_ITERATOR 1
#define HAVE_DECL_MKSTEMP 1
#define HAVE_DECL_SNPRINTF 1
#define HAVE_DECL_VSNPRINTF 1
#define HAVE_DECL__SNPRINTF 0
#define HAVE_DECL__SNWPRINTF 0
#define HAVE_DIRENT_H 1
#define HAVE_DLFCN_H 1
#define HAVE_GETCWD 1
#define HAVE_GETEGID 1
#define HAVE_GETEUID 1
#define HAVE_GETGID 1
#define HAVE_GETPAGESIZE 1
#define HAVE_GETTEXT 1
#define HAVE_GETUID 1
#define HAVE_ICONV 1
#define HAVE_INTTYPES_H 1
#define HAVE_IOS 1
#define HAVE_ISTREAM 1
#define HAVE_KPSEWHICH 1
#define HAVE_LANGINFO_CODESET 1
#define HAVE_LC_MESSAGES 1
#define HAVE_LIBC 1
#define HAVE_LIBM 1
#define HAVE_LIMITS 1
#define HAVE_LIMITS_H 1
#define HAVE_LOCALE 1
#define HAVE_LOCALE_H 1
#define HAVE_LONG_DOUBLE 1
#define HAVE_LONG_LONG 1
#define HAVE_MALLOC_H 1
#define HAVE_MEMMOVE 1
#define HAVE_MEMORY_H 1
#define HAVE_MEMSET 1
#define HAVE_MKFIFO 1
#define HAVE_MKSTEMP 1
#define HAVE_MKTEMP 1
#define HAVE_MMAP 1
#define HAVE_MUNMAP 1
#define HAVE_NL_TYPES_H 1
#define HAVE_OSTREAM 1
#define HAVE_POSIX_PRINTF 1
#define HAVE_PUTENV 1
#define HAVE_SETENV 1
#define HAVE_SETLOCALE 1
#define HAVE_SNPRINTF 1
#define HAVE_SSTREAM 1
#define HAVE_STDDEF_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STD_COUNT 1
#define HAVE_STRCASECMP 1
#define HAVE_STRCHR 1
#define HAVE_STRDUP 1
#define HAVE_STRERROR 1
#define HAVE_STRINGS_H 1
#define HAVE_STRING_H 1
#define HAVE_STRTOUL 1
#define HAVE_SYS_PARAM_H 1
#define HAVE_SYS_SELECT_H 1
#define HAVE_SYS_SOCKET_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_TSEARCH 1
#define HAVE_UNISTD_H 1
#define HAVE_UNSIGNED_LONG_LONG 1
#define HAVE_VSNPRINTF 1
#define HAVE_WCHAR_T 1
#define HAVE_WCSLEN 1
#define HAVE_WINT_T 1
#define HAVE_X11_FLIMAGE_H 1
#define HAVE_ZLIB_H 1
#define ICONV_CONST const
#define INTDIV0_RAISES_SIGFPE 1
#define MODERN_STL_STREAMS 1
#define PACKAGE "lyx"
#define PACKAGE_BUGREPORT "[EMAIL PROTECTED]"
#define PACKAGE_NAME "lyx"
#define PACKAGE_STRING "lyx 1.4.0cvs"
#define PACKAGE_TARNAME "lyx"
#define PACKAGE_VERSION "1.4.0cvs"
#define RETSIGTYPE void
#define SELECT_TYPE_ARG1 int
#define SELECT_TYPE_ARG234 (fd_set *)
#define SELECT_TYPE_ARG5 (struct timeval *)
#define SIZE_MAX 4294967295U
#define STDC_HEADERS 1
#define TIME_WITH_SYS_TIME 1
#define USE_ASPELL 1
#define USE_COMRESSION 1
#define USE_JPEG_IMAGE_LOADER 1
#define VERSION "1.4.0cvs"
#define WITH_WARNINGS 1
#ifndef _ALL_SOURCE
#endif
#define uintmax_t unsigned long long
#ifndef HAVE_STRCHR
# define strchr(a,b)index(a,b)
#endif
#ifndef HAVE_MEMMOVE
# define memmove(a,b,c) bcopy(b,a,c)
#endif
#ifndef HAVE_STRERROR
#if defined(__cplusplus)
#endif
#endif
#ifdef BROKEN_HEADERS
#include "broken_headers.h"
#endif
#ifdef HAVE_MKSTEMP
#ifndef HAVE_DECL_MKSTEMP
#if defined(__cplusplus)
#endif
#endif
#endif
#ifdef __EMX__
#include "support/os2_defines.h"
#endif
#if defined(HAVE_OSTREAM) && defined(HAVE_LOCALE) && defined(HAVE_SSTREAM)
#define USE_BOOST_FORMAT 1
#else
#define USE_BOOST_FORMAT 0
#endif
#define BOOST_USER_CONFIG 
#if defined(ENABLE_ASSERTIONS)
#define BOOST_ENABLE_ASSERT_HANDLER 1
#else
#define BOOST_DISABLE_ASSERTS 1
#endif
#define BOOST_DISABLE_THREADS 1
#define BOOST_NO_WREGEX 1
#define BOOST_NO_WSTRING 1
#endif

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Angus Leeming wrote:
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++?
$ cat test.C
#include 
int main () { return 0; }
$ g++33 -DHAVE_CONFIG_H -Iboost/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: removing   -DBOOST_USER_CONFIG=""  from the compile
line above, solves the problem.
Does that bring us any closer?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 preliminary guess, looking at the  you posted, try
#define uintmax_t unsigned long long
#include 
int main () { return 0; }
Compile with a normal
$ gcc -I/boost -o trial trial.C
Anyway, I'm sure that you get the point and can find the offender
from here.
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?
Actually, your suggestion to put another #define in the trial.C file,
is totally uncomprehesible for me :(. Don't see at all what it means.
Rob.

Re: Mailinglist issue: gmane archive does not hide email addresses

[Rob Lahaye]

[EMAIL PROTECTED] wrote:
On Thu, Jun 03, 2004 at 05:46:16PM +0900, Rob Lahaye wrote:
All these archives are publicly available, which means someone can collect
the emails from there for third parties spam-junk stuff, if the sender's
email address is not hidden; mail-archive and theaimsgroup do this nicely!

theaimsgroup is the worst, if you want my opinion.  Within hours of posting
to a list there, the address I use gets spammed.  Tried it many times.

But here is, I believe, where the trouble with gmane.org starts: all emails
are 'as-is' on this archive, nothing is hidden! Which means, it's an
excellent source for spam/junk distibutors to add all lyx-devel contributors
to their list of email addresses.

There are many developers who read this list as news; they need gmane.  


So, the carefullness by the subscription mechanism and the 
mail-archive/theaimsgroup
hiding strategy, is made totally redundant by forwarding everything 
automatically
also to the gmane.org.
Actually, by forcing the use of a legitimate email address by the 
subscription
mechanism, we are also forced to have our legitimate email address 
published on the
public gmane archive. This is a very bad construction!


Can you back up your claim about gmane not hiding the aaddresses?  Have you
read
http://gmane.org/tmda.php
No I haven't. I find it rather complicated though.
What do you think of this excerpt:
   While the X-Archive header makes all addresses in your message be encrypted,
   if somebody on the mailing list responds to your message, it's still likely
   that your real email address will be included in the follow-up. It's probably
   more useful to switch encryption on for the entire list.
Encription of entire list!?! Sounds like that would solve the exposure of email
addresses for everyone, especially new subscribers; old subscribers are already
exposed until now :(.
Sorry, I'm not an email expert; don't know about setting X-archive fields etc.
I'm only worried about the increasing amount of spam arriving at my inbox (yes,
yes, I use a spam filter.).
Rob.
By the way: are you "[EMAIL PROTECTED]"? It's just there on gmane archive!

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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?
Actually, your suggestion to put another #define in the trial.C
file, is totally uncomprehesible for me :(. Don't see at all what it
means.

 is included from within  if you pass
-DBOOST_USER_CONFIG="" to the compiler.
So, rather than pass this macro to the compiler I was telling you
to compile this 'normally'. Ie without the macro.
#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 in src/config.h:
/* Define to unsigned long or unsigned long long if  and
don't define. */
#define uintmax_t unsigned long long
which obviously causes the trouble. Apparently, this clashes with what
I have in /usr/include/machine/ansi.h:
typedef unsigned long long  __uint64_t;
Or another typedef elsewhere? Does this bring us any closer?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Angus Leeming wrote:
Sigh.
I'd like you to post a minimal, failing program of the form
#define uintmax_t unsigned long long
#include 
int main() { return 0; }
where the #define is taken from your config.h file.
Right, you've got it already. So here we go again:
$ cat test.C
#define 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: redeclaration of C++ built-in type `long'
Is this enough, or am I supposed to provide more info?
Please bear with me; I'm still not so sure what I'm doingdon't know
anything about what is happening in the boost stuff, and why this all
of a sudden clashes with the config.h file.
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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/cstdint.hpp
===
RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v
retrieving revision 1.5
diff -u -r1.5 cstdint.hpp
--- boost/boost/cstdint.hpp  2004/02/05 09:14:14 1.5
+++ boost/boost/cstdint.hpp  2004/06/02 08:24:38
@@ -118,7 +118,7 @@
   typedef uint64_t uint_fast64_t;
   typedef int64_t intmax_t;
-  typedef uint64_t uintmax_t;
+//  typedef uint64_t uintmax_t;
 # else
Any ideas why this obstructs the compilation?
Compiler: gcc 3.3.4 20040505 (prerelease)
Regards,
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
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, to successfully compile CVS:

| Index: boost/boost/cstdint.hpp
| ===
| RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v
| retrieving revision 1.5
| diff -u -r1.5 cstdint.hpp
| --- boost/boost/cstdint.hpp  2004/02/05 09:14:14 1.5
| +++ boost/boost/cstdint.hpp  2004/06/02 08:24:38
| @@ -118,7 +118,7 @@
| typedef uint64_t uint_fast64_t;
| typedef int64_t intmax_t;
| -  typedef uint64_t uintmax_t;
| +//  typedef uint64_t uintmax_t;
|   # else

| Any ideas why this obstructs the compilation?
| Compiler: gcc 3.3.4 20040505 (prerelease)
I doubt that this has anything to do with the compiler. I do not see
the problem with gcc 3.3.2 , 3.3.3 nor 3.5 prerelease.
What is the full error message you get? And what kind of system are
you compiling on?
autogen.sh:
 Using autoconf (GNU Autoconf) 2.53
gmake:
[...snip...]
gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src'
source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \
depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
 /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -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: 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]
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
Rob Lahaye [EMAIL PROTECTED] writes:
| autogen.sh:
|   Using autoconf (GNU Autoconf) 2.53
| gmake:
| [...snip...]
| gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src'
| source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \
| depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \
| depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
| /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
|   /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -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: 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?
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 /usr/include/inttypes.h
$ grep -n uint32_t /usr/include/inttypes.h
/usr/include/inttypes.h:18:typedef  __uint32_t  uint32_t;
Is that causing the trouble?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 as in inttypes.h

| This is what I get:
| $ grep -n uintmax_t /usr/include/inttypes.h
| $ grep -n uint32_t /usr/include/inttypes.h
| /usr/include/inttypes.h:18:typedef  __uint32_t  uint32_t;

| Is that causing the trouble?
Not directly. This compiles:
typedef long tull;
typedef tull tall;
int main() 
{}

Where does __uint32_t come from?
All this is going a bit beyond my level of understanding the compilation process.
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;
2) When I keep the offending typedef line in boost/boost/cstdint.hpp
   and comment out in  /usr/include/inttypes.h  this line:
   //typedef   __uint64_t  uint64_t;
   I get another (obvious?) error during the compilation:
[...snip...]
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG=config.h -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
 /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-I/usr/local/include -I/usr/X11R6/include -DBOOST_USER_CONFIG=config.h -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:116: error: `uint64_t' not declared
../../../../boost/boost/cstdint.hpp:117: error: syntax error before `;' token
../../../../boost/boost/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.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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/cstdint.hpp
===
RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v
retrieving revision 1.5
diff -u -r1.5 cstdint.hpp
--- boost/boost/cstdint.hpp  2004/02/05 09:14:14 1.5
+++ boost/boost/cstdint.hpp  2004/06/02 08:24:38
@@ -118,7 +118,7 @@
   typedef uint64_t uint_fast64_t;
   typedef int64_t intmax_t;
-  typedef uint64_t uintmax_t;
+//  typedef uint64_t uintmax_t;
 # else
Any ideas why this obstructs the compilation?
Compiler: gcc 3.3.4 20040505 (prerelease)
Regards,
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
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, to successfully compile CVS:

| Index: boost/boost/cstdint.hpp
| ===
| RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v
| retrieving revision 1.5
| diff -u -r1.5 cstdint.hpp
| --- boost/boost/cstdint.hpp  2004/02/05 09:14:14 1.5
| +++ boost/boost/cstdint.hpp  2004/06/02 08:24:38
| @@ -118,7 +118,7 @@
| typedef uint64_t uint_fast64_t;
| typedef int64_t intmax_t;
| -  typedef uint64_t uintmax_t;
| +//  typedef uint64_t uintmax_t;
|   # else

| Any ideas why this obstructs the compilation?
| Compiler: gcc 3.3.4 20040505 (prerelease)
I doubt that this has anything to do with the compiler. I do not see
the problem with gcc 3.3.2 , 3.3.3 nor 3.5 prerelease.
What is the full error message you get? And what kind of system are
you compiling on?
autogen.sh:
 Using autoconf (GNU Autoconf) 2.53
gmake:
[...snip...]
gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src'
source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \
depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
 /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-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,
 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) [FreeBSD]
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:
| autogen.sh:
|   Using autoconf (GNU Autoconf) 2.53
| gmake:
| [...snip...]
| gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src'
| source='cpp_regex_traits.cpp' object='cpp_regex_traits.lo' libtool=yes \
| depfile='.deps/cpp_regex_traits.Plo' tmpdepfile='.deps/cpp_regex_traits.TPlo' \
| depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
| /usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
|   /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-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,
|   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) [FreeBSD]
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/include/inttypes.h
$ grep -n uint32_t /usr/include/inttypes.h
/usr/include/inttypes.h:18:typedef  __uint32_t  uint32_t;
Is that causing the trouble?
Rob.

Re: boost/cstdint.hpp:121: error

[Rob Lahaye]

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 typdeffed/defined as in 

| This is what I get:
| $ grep -n uintmax_t /usr/include/inttypes.h
| $ grep -n uint32_t /usr/include/inttypes.h
| /usr/include/inttypes.h:18:typedef  __uint32_t  uint32_t;

| Is that causing the trouble?
Not directly. This compiles:
typedef long tull;
typedef tull tall;
int main() 
{}

Where does __uint32_t come from?
All this is going a bit beyond my level of understanding the compilation process.
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;
2) When I keep the offending typedef line in boost/boost/cstdint.hpp
   and comment out in  /usr/include/inttypes.h  this line:
   //typedef   __uint64_t  uint64_t;
   I get another (obvious?) error during the compilation:
[...snip...]
depmode=gcc3 /usr/local/bin/bash ../../../../config/depcomp \
/usr/local/bin/bash ../../../../libtool --mode=compile /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. 
-I../../../../src -I../../../../boost  -I/usr/local/include   -I/usr/X11R6/include 
-DBOOST_USER_CONFIG="" -g -O -fno-exceptions -W -Wall -c -o 
cpp_regex_traits.lo `test -f cpp_regex_traits.cpp || echo './'`cpp_regex_traits.cpp
 /usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost 
-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,
 from cpp_regex_traits.cpp:22:
../../../../boost/boost/cstdint.hpp:116: error: `uint64_t' not declared
../../../../boost/boost/cstdint.hpp:117: error: syntax error before `;' token
../../../../boost/boost/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.

boost/cstdint.hpp:121: error

[Rob Lahaye]

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
This is on FreeBSD (4.10), using Gcc 3.3.4 (20040505).
Rob.

boost/cstdint.hpp:121: error

[Rob Lahaye]

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
This is on FreeBSD (4.10), using Gcc 3.3.4 (20040505).
Rob.

Lyx About: license 1995 - 2001 / shouldn't that be 2004?

[Rob Lahaye]

Sorry, just a rediculous detail.

Help-About LyX..., License tab.

Doesn't the LyX Team still have the license/copyrights?
Shouldn't that be 2004 then?
Cheers,
Rob.

Lyx About: license 1995 - 2001 / shouldn't that be 2004?

[Rob Lahaye]

Sorry, just a rediculous detail.

"Help->About LyX...", License tab.

Doesn't the LyX Team still have the license/copyrights?
Shouldn't that be 2004 then?
Cheers,
Rob.

./autogen.sh + ./configure problems with 2.57

[Rob Lahaye]

Hi,

./autogen.sh and ./configure get stuck:

---
$ ./autogen.sh
Using autoconf (GNU Autoconf) 2.57
Locating GNU m4... /usr/local/bin/gm4
Generate acinclude.m4... done.
Building macros...
.
lib/reLyX
done.
Building config header template...
.
autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
done.
Building Makefile templates...
.
lib/reLyX
done.
Building configure...
   .
   lib/reLyX
done.
Building lib/configure ... done.
run ./configure ; make

$./configure --prefix=/opt --with-extra-prefix=/usr/local
./configure: line 1309: syntax error near unexpected token `src/config.h'
./configure: line 1309: `AM_CONFIG_HEADER(src/config.h)'
$
---
Any idea why this is going wrong?

Rob.

./autogen.sh + ./configure problems with 2.57

[Rob Lahaye]

Hi,

./autogen.sh and ./configure get stuck:

---
$ ./autogen.sh
Using autoconf (GNU Autoconf) 2.57
Locating GNU m4... /usr/local/bin/gm4
Generate acinclude.m4... done.
Building macros...
.
lib/reLyX
done.
Building config header template...
.
autoheader: error: AC_CONFIG_HEADERS not found in configure.ac
done.
Building Makefile templates...
.
lib/reLyX
done.
Building configure...
   .
   lib/reLyX
done.
Building lib/configure ... done.
run "./configure ; make"

$./configure --prefix=/opt --with-extra-prefix=/usr/local
./configure: line 1309: syntax error near unexpected token `src/config.h'
./configure: line 1309: `AM_CONFIG_HEADER(src/config.h)'
$
---
Any idea why this is going wrong?

Rob.

Re: pthread problems

[Rob Lahaye]

Martti Kuparinen wrote:
Hi!

I'm maintaining lyx on NetBSD. I'm updating our packages to 1.3.4 and while
the lyx-xforms package works okay lyx-qt gives me this upon shutdown:
LyX: Done!
lyx: Error detected by libpthread: Destroying locked mutex.
Detected by file /home/netbsd/src/lib/libpthread/pthread_mutex.c, line 
135, function pthread_mutex_destroy.
See pthread(3) for information.
Abort trap (core dumped)

How should I debug this further? I'll rebuild lyx and submit backtraces
from gdb...
I remember similar things happened here when I compiled with Qt.
I believe it was caused by the Qt libs which were compiled with
threads by default from the ports.
However, threads are not needed for LyX and thus LyX/Qt developers
will say: get/create Qt libs without threads. At least that how
I remember this discussion ended.
Keep in mind that I myself am not at all a threads expert!

Rob.

Re: pthread problems

[Rob Lahaye]

Martti Kuparinen wrote:
Hi!

I'm maintaining lyx on NetBSD. I'm updating our packages to 1.3.4 and while
the lyx-xforms package works okay lyx-qt gives me this upon shutdown:
LyX: Done!
lyx: Error detected by libpthread: Destroying locked mutex.
Detected by file "/home/netbsd/src/lib/libpthread/pthread_mutex.c", line 
135, function "pthread_mutex_destroy".
See pthread(3) for information.
Abort trap (core dumped)

How should I debug this further? I'll rebuild lyx and submit backtraces
from gdb...
I remember similar things happened here when I compiled with Qt.
I believe it was caused by the Qt libs which were compiled with
threads by default from the ports.
However, threads are not needed for LyX and thus LyX/Qt developers
will say: "get/create Qt libs without threads". At least that how
I remember this discussion ended.
Keep in mind that I myself am not at all a threads expert!

Rob.

Re: Boost, threading and FreeBSD problem

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:

| I cannot see any obvious macros to turn on/off, but I'll experiment a
| bit.
Ok, can you try this patch please.
Bingo!
Works fine here.
Thanks.
Rob.

Re: Boost, threading and FreeBSD problem

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:

| I cannot see any obvious macros to turn on/off, but I'll experiment a
| bit.
Ok, can you try this patch please.
Bingo!
Works fine here.
Thanks.
Rob.

Re: Boost, threading and FreeBSD problem

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
Rob Lahaye [EMAIL PROTECTED] writes:

| Hi,

| There's a problem with threading since recent boost updates in CVS,
| at least for my FreeBSD PC.
| My make ends with:

| [...]
| /usr/local/bin/g++33 -g -O -fno-exceptions -W -Wall -o tex2lyx FloatList.o 
Floating.o counters.o lengthcommon.o lyxlayout.o lyxtextclass.o lyxlex.o 
lyxlex_pimpl.o boost.o context.o gettext.o lyxfont.o texparser.o tex2lyx.o preamble.o 
math.o table.o text.o  -L/opt/lib -L/usr/local/lib ../support/.libs/libsupport.a 
../../boost/libs/regex/src/.libs/libboostregex.a -lz
| ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_init_threads()':
| 
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:88:
 undefined reference to `pthread_mutex_init'
| ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_free_threads()':
| 
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:93:
 undefined reference to `pthread_mutex_destroy'
| collect2: ld returned 1 exit status
| gmake[4]: *** [tex2lyx] Error 1
| On my FreeBSD PC, there should be something like this set before compilation:
|   setenv CXXFLAGS -D_THREAD_SAFE
|   setenv CFLAGS -D_THREAD_SAFE
|   setenv LDFLAGS -pthread
| I suppose this should be added somethere in the autoconf script.

I think the correct solution is to set the BOOST provided macro to
just turn threading support off.
I'll have a look.

Lars, at the moment this is the show-stopper on FreeBSD.
Am I the only FreeBSD user trying to compile CVS on my PC?
Cheers,
Rob.

Re: Boost, threading and FreeBSD problem

[Rob Lahaye]

Lars Gullik Bjønnes wrote:
Rob Lahaye <[EMAIL PROTECTED]> writes:

| Hi,

| There's a problem with threading since recent boost updates in CVS,
| at least for my FreeBSD PC.
| My make ends with:

| [...]
| /usr/local/bin/g++33 -g -O -fno-exceptions -W -Wall -o tex2lyx FloatList.o 
Floating.o counters.o lengthcommon.o lyxlayout.o lyxtextclass.o lyxlex.o 
lyxlex_pimpl.o boost.o context.o gettext.o lyxfont.o texparser.o tex2lyx.o preamble.o 
math.o table.o text.o  -L/opt/lib -L/usr/local/lib ../support/.libs/libsupport.a 
../../boost/libs/regex/src/.libs/libboostregex.a -lz
| ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_init_threads()':
| 
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:88:
 undefined reference to `pthread_mutex_init'
| ../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_free_threads()':
| 
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:93:
 undefined reference to `pthread_mutex_destroy'
| collect2: ld returned 1 exit status
| gmake[4]: *** [tex2lyx] Error 1
| On my FreeBSD PC, there should be something like this set before compilation:
|   setenv CXXFLAGS -D_THREAD_SAFE
|   setenv CFLAGS -D_THREAD_SAFE
|   setenv LDFLAGS -pthread
| I suppose this should be added somethere in the autoconf script.

I think the correct solution is to set the BOOST provided macro to
just turn threading support off.
I'll have a look.

Lars, at the moment this is the show-stopper on FreeBSD.
Am I the only FreeBSD user trying to compile CVS on my PC?
Cheers,
Rob.

Boost, threading and FreeBSD problem

[Rob Lahaye]

Hi,

There's a problem with threading since recent boost updates in CVS,
at least for my FreeBSD PC.
My make ends with:

[...]
/usr/local/bin/g++33 -g -O -fno-exceptions -W -Wall -o tex2lyx FloatList.o Floating.o 
counters.o lengthcommon.o lyxlayout.o lyxtextclass.o lyxlex.o lyxlex_pimpl.o boost.o 
context.o gettext.o lyxfont.o texparser.o tex2lyx.o preamble.o math.o table.o text.o  
-L/opt/lib -L/usr/local/lib ../support/.libs/libsupport.a 
../../boost/libs/regex/src/.libs/libboostregex.a -lz
../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_init_threads()':
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:88:
 undefined reference to `pthread_mutex_init'
../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_free_threads()':
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:93:
 undefined reference to `pthread_mutex_destroy'
collect2: ld returned 1 exit status
gmake[4]: *** [tex2lyx] Error 1
On my FreeBSD PC, there should be something like this set before compilation:
setenv CXXFLAGS -D_THREAD_SAFE
setenv CFLAGS -D_THREAD_SAFE
setenv LDFLAGS -pthread
I suppose this should be added somethere in the autoconf script.

Regards,
Rob.

Boost, threading and FreeBSD problem

[Rob Lahaye]

Hi,

There's a problem with threading since recent boost updates in CVS,
at least for my FreeBSD PC.
My make ends with:

[...]
/usr/local/bin/g++33 -g -O -fno-exceptions -W -Wall -o tex2lyx FloatList.o Floating.o 
counters.o lengthcommon.o lyxlayout.o lyxtextclass.o lyxlex.o lyxlex_pimpl.o boost.o 
context.o gettext.o lyxfont.o texparser.o tex2lyx.o preamble.o math.o table.o text.o  
-L/opt/lib -L/usr/local/lib ../support/.libs/libsupport.a 
../../boost/libs/regex/src/.libs/libboostregex.a -lz
../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_init_threads()':
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:88:
 undefined reference to `pthread_mutex_init'
../../boost/libs/regex/src/.libs/libboostregex.a(regex_synch.o): In function 
`boost::re_detail::re_free_threads()':
/home/lahaye/SOFTWARE/lyx-devel/boost/libs/regex/src/../../../../boost/boost/regex/v4/regex_synch.hpp:93:
 undefined reference to `pthread_mutex_destroy'
collect2: ld returned 1 exit status
gmake[4]: *** [tex2lyx] Error 1
On my FreeBSD PC, there should be something like this set before compilation:
setenv CXXFLAGS -D_THREAD_SAFE
setenv CFLAGS -D_THREAD_SAFE
setenv LDFLAGS -pthread
I suppose this should be added somethere in the autoconf script.

Regards,
Rob.

Re: FormDocument.C: FD_document_language has no member combox_language

[Rob Lahaye]

Angus Leeming wrote:
Rob Lahaye wrote:

Compiling CVS, ends with:

 [...]
 FormDocument.C: In member function `virtual void
 FormDocument::build()': FormDocument.C:270: error: 'struct
 FD_document_language' has no member named 'combox_language'
 FormDocument.C:285: error: 'struct FD_document_language' has no


I don't have 1.4.x here at work. However, these variables are created 
by manipulating the output from 'fdesign -convert' using some sed 
Thanks Angus; I moved my own patched form_document.fd out of the way
and updated it from CVS. Then all went OK; well, other problems occurred
which I'll report next email.
Cheers,
Rob.

Re: FormDocument.C: FD_document_language has no member combox_language

[Rob Lahaye]

Angus Leeming wrote:
Rob Lahaye wrote:

Compiling CVS, ends with:

 [...]
 FormDocument.C: In member function `virtual void
 FormDocument::build()': FormDocument.C:270: error: 'struct
 FD_document_language' has no member named 'combox_language'
 FormDocument.C:285: error: 'struct FD_document_language' has no


I don't have 1.4.x here at work. However, these variables are created 
by manipulating the output from 'fdesign -convert' using some sed 
Thanks Angus; I moved my own patched "form_document.fd" out of the way
and updated it from CVS. Then all went OK; well, other problems occurred
which I'll report next email.
Cheers,
Rob.

FormDocument.C: FD_document_language has no member combox_language

[Rob Lahaye]

Hi,

Compiling CVS, ends with:

 [...]
 FormDocument.C: In member function `virtual void FormDocument::build()':
 FormDocument.C:270: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C:285: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C:288: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C: In member function `bool FormDocument::language_apply(BufferParams)':
 FormDocument.C:975: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C: In member function `void FormDocument::language_update(const 
BufferParams)':
 FormDocument.C:1147: error: 'struct FD_document_language' has no member named 
'combox_language'
 gmake[6]: *** [FormDocument.lo] Error 1
I'm using xforms-1.0; is there a conflict here?

Rob.

FormDocument.C: FD_document_language has no member combox_language

[Rob Lahaye]

Hi,

Compiling CVS, ends with:

 [...]
 FormDocument.C: In member function `virtual void FormDocument::build()':
 FormDocument.C:270: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C:285: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C:288: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C: In member function `bool FormDocument::language_apply(BufferParams&)':
 FormDocument.C:975: error: 'struct FD_document_language' has no member named 
'combox_language'
 FormDocument.C: In member function `void FormDocument::language_update(const 
BufferParams&)':
 FormDocument.C:1147: error: 'struct FD_document_language' has no member named 
'combox_language'
 gmake[6]: *** [FormDocument.lo] Error 1
I'm using xforms-1.0; is there a conflict here?

Rob.

CVS File-New crash; math related

[Rob Lahaye]

Hi,

Maybe Andre knows already; if not:

SISSEGV crash occurs after:

Start LyX
File-New
Insert Math
File-Close [and Discard Safe]
File-New
/Bang/
Cheers,
Rob.

CVS File->New crash; math related

[Rob Lahaye]

Hi,

Maybe Andre knows already; if not:

SISSEGV crash occurs after:

Start LyX
File->New
Insert Math
File->Close [and Discard Safe]
File->New
/Bang/
Cheers,
Rob.

Crash with mathed

[Rob Lahaye]

Hi,

Current CVS with xforms crashes as follows:

Start LyX
File-New
Insert Math
lyx: SIGSEGV signal caught

(Sorry can't make a backtrace at this stage).

Regards,
Rob.

Crash with mathed

[Rob Lahaye]

Hi,

Current CVS with xforms crashes as follows:

Start LyX
File->New
Insert Math
lyx: SIGSEGV signal caught

(Sorry can't make a backtrace at this stage).

Regards,
Rob.

CVS can't compile in xforms directory !?!

[Rob Lahaye]

Hi,

CVS compilation gets stuck at:

[...]
gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/src/frontends/xforms'
cmp -s lyx_forms.h-tmp lyx_forms.h || {\
rm -f lyx_forms.h ;\
cp lyx_forms.h-tmp lyx_forms.h ;\
}
echo timestamp  stamp-forms
if cmp -s lyx_xpm.h-tmp lyx_xpm.h || {\
rm -f lyx_xpm.h ;\
cp lyx_xpm.h-tmp lyx_xpm.h ;\
}
/usr/local/bin/bash: -c: line 2: syntax error: unexpected end of file
gmake[4]: *** [stamp-xpm] Error 2
Syntac error? Could it be that you should use (...) instead of {...} here
for grouping commands?
This is up-to-date LyX-CVS on FreeBSD box.

Rob.

Remove stray if in src/frontends/xforms/Makefile.am

[Rob Lahaye]

Angus,

Apologies for the person-to-person email, but my emails to the devel list
seem to end up in /dev/null :(.
Another patch is needed to src/frontends/xforms/Makefile.am in CVS, to
remove a stray 'if':
Index: src/frontends/xforms/Makefile.am
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/Makefile.am,v
retrieving revision 1.111
diff -u -r1.111 Makefile.am
--- src/frontends/xforms/Makefile.am2003/11/30 17:11:50 1.111
+++ src/frontends/xforms/Makefile.am2003/12/01 07:24:42
@@ -194,7 +194,7 @@
@:
 stamp-xpm: lyx_xpm.h-tmp
-   if cmp -s $ lyx_xpm.h || {\
+   cmp -s $ lyx_xpm.h || {\
rm -f lyx_xpm.h ;\
cp $ lyx_xpm.h ;\
}
Cheers,
Rob.

CVS can't compile in xforms directory !?!

[Rob Lahaye]

Hi,

CVS compilation gets stuck at:

[...]
gmake[4]: Entering directory `/home/lahaye/SOFTWARE/lyx-devel/src/frontends/xforms'
cmp -s lyx_forms.h-tmp lyx_forms.h || {\
rm -f lyx_forms.h ;\
cp lyx_forms.h-tmp lyx_forms.h ;\
}
echo timestamp > stamp-forms
if cmp -s lyx_xpm.h-tmp lyx_xpm.h || {\
rm -f lyx_xpm.h ;\
cp lyx_xpm.h-tmp lyx_xpm.h ;\
}
/usr/local/bin/bash: -c: line 2: syntax error: unexpected end of file
gmake[4]: *** [stamp-xpm] Error 2
Syntac error? Could it be that you should use "(...)" instead of "{...}" here
for grouping commands?
This is up-to-date LyX-CVS on FreeBSD box.

Rob.

Remove stray "if" in src/frontends/xforms/Makefile.am

[Rob Lahaye]

Angus,

Apologies for the person-to-person email, but my emails to the devel list
seem to end up in /dev/null :(.
Another patch is needed to src/frontends/xforms/Makefile.am in CVS, to
remove a stray 'if':
Index: src/frontends/xforms/Makefile.am
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/Makefile.am,v
retrieving revision 1.111
diff -u -r1.111 Makefile.am
--- src/frontends/xforms/Makefile.am2003/11/30 17:11:50 1.111
+++ src/frontends/xforms/Makefile.am2003/12/01 07:24:42
@@ -194,7 +194,7 @@
@:
 stamp-xpm: lyx_xpm.h-tmp
-   if cmp -s $< lyx_xpm.h || {\
+   cmp -s $< lyx_xpm.h || {\
rm -f lyx_xpm.h ;\
cp $< lyx_xpm.h ;\
}
Cheers,
Rob.

fdesign -convert form_external.fd} failed. Please investigate.

[Rob Lahaye]

This is the end of the 'make' for current LyX/CVS:

[...snip...]
/usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I./.. 
-I../../../../src -I.. -I/opt/include -I/usr/local/include -I/usr/X11R6/include -g -O 
-fno-exceptions -W -Wall -MT form_ert.lo -MD -MP -MF .deps/form_ert.Tpo -c form_ert.C
echo timestamp  form_ert.lo
/bin/sh ./fdfix.sh form_external.fd
In TypeValue [fd_objects.c 634] type  is unknown
In FindClassStruct [fd_objects.c 124] Can't find class 0
unknown class 0
Segmentation fault (core dumped)
fdesign -convert form_external.fd} failed. Please investigate.
make[6]: *** [form_external.C] Error 1
Is this a bug in LyX or a problem with Xforms?
Maybe this form_external.fd has been created with a too new/old version of fdesign?
I'm using xforms version 1.0.2, but I don't think that fdesign differs from the
latest official release, or has it?
I have then upgraded to latest Xforms/CVS, but still got exactly the same error.
Rob.

Re: fdesign -convert form_external.fd} failed. Please investigate.

[Rob Lahaye]

Rob Lahaye wrote:
 
 
 This is the end of the 'make' for current LyX/CVS:
 
Ah, hold on for a moment; this is possibly due to my
own changes to form_external.fd! Forgot about that.
I'll investigate myself first.
Sorry for the noise.

Rob.

"fdesign -convert form_external.fd}" failed. Please investigate.

[Rob Lahaye]

This is the end of the 'make' for current LyX/CVS:

[...snip...]
/usr/local/bin/g++33 -DHAVE_CONFIG_H -I. -I. -I../../../../src -I./.. 
-I../../../../src -I.. -I/opt/include -I/usr/local/include -I/usr/X11R6/include -g -O 
-fno-exceptions -W -Wall -MT form_ert.lo -MD -MP -MF .deps/form_ert.Tpo -c form_ert.C
echo timestamp > form_ert.lo
/bin/sh ./fdfix.sh form_external.fd
In TypeValue [fd_objects.c 634] type  is unknown
In FindClassStruct [fd_objects.c 124] Can't find class 0
unknown class 0
Segmentation fault (core dumped)
"fdesign -convert form_external.fd}" failed. Please investigate.
make[6]: *** [form_external.C] Error 1
Is this a bug in LyX or a problem with Xforms?
Maybe this form_external.fd has been created with a too new/old version of fdesign?
I'm using xforms version 1.0.2, but I don't think that fdesign differs from the
latest official release, or has it?
I have then upgraded to latest Xforms/CVS, but still got exactly the same error.
Rob.

Re: "fdesign -convert form_external.fd}" failed. Please investigate.

[Rob Lahaye]

Rob Lahaye wrote:
> 
> 
> This is the end of the 'make' for current LyX/CVS:
> 
Ah, hold on for a moment; this is possibly due to my
own changes to form_external.fd! Forgot about that.
I'll investigate myself first.
Sorry for the noise.

Rob.

Re: Subscribe to devel-mailing-list without receiving emails. Possible?

[Rob Lahaye]

Rob Lahaye wrote:
Is there a way that allows me to send emails to the devel-list, but
that will not send all lyx-devel emails to my subscription address?
Jean-Marc Lasgouttes wrote:
 It seems to me that, if you are not a subscriber and send a message,
 all you have to do is send a confirmation to some daemon and then you
 will be 'whitelisted' and allowed to post.

 Did you try that?
Oh, maybe I tried once and considered the confirmation rather as a rejection.

Angus Leeming wrote:
Subscribe to the service and the mails that you receive telling you 
what step to take to confirm the subscription etc will also tell you 
where to find the web page that provides access to your mail delivery 
preferences. Go there and select the do not receive mail check box.
Here is what I got, after subscribing, which doesn't tell me
any webpage for making changes:
---
Hi! This is the ezmlm program. I'm managing the
[EMAIL PROTECTED] mailing list.
Acknowledgment: I have added the address

   [EMAIL PROTECTED]

to the lyx-devel mailing list.

Welcome to [EMAIL PROTECTED]

Please save this message so that you know the address you are
subscribed under, in case you later want to unsubscribe or change your
subscription address.
--- Administrative commands for the lyx-devel list ---

I can handle administrative requests automatically. Please
DO NOT SEND THEM TO THE LIST ADDRESS! If you do, I will not
see them and other subscribers will be annoyed. Instead, send
your message to the correct command address:
To subscribe to the list, send a message to:
   [EMAIL PROTECTED]
To remove your address from the list, send a message to:
   [EMAIL PROTECTED]
Similar addresses exist for the digest list:
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]
To get messages 123 through 145 (a maximum of 100 per request), mail:
   [EMAIL PROTECTED]
To get an index with subject and author for messages 123-456 , mail:
   [EMAIL PROTECTED]
They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.
To get an index with subject and author for the last 100-200
messages (this also tells you the latest message number), mail:
   [EMAIL PROTECTED]
To receive all messages with the same subject as message 12345,
send an empty message to:
   [EMAIL PROTECTED]
The messages do not really need to be empty, but I will ignore
their content. Only the ADDRESS you send to is important.
You can start a subscription for an alternate address,
for example [EMAIL PROTECTED], just add a hyphen and your
address (with '=' instead of '@') after the command word:
[EMAIL PROTECTED]
To stop subscription for this address, mail:
[EMAIL PROTECTED]
In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.
If despite following these instructions, you do not get the
desired results, please contact my owner at
[EMAIL PROTECTED] Please be patient, my owner is a
lot slower than I am
--- Enclosed is a copy of the request I received.

Re: Subscribe to devel-mailing-list without receiving emails. Possible?

[Rob Lahaye]

Angus Leeming wrote:
 Rob Lahaye wrote:
 
Here is what I got, after subscribing, which doesn't tell me
any webpage for making changes:
 
 
 My apologies then.
 
 What happens when you send a mail to 
 [EMAIL PROTECTED] for a help message?

Not useful either.

If you recommend me to visit certain webpage for this,
why not you tell me the webpage directly :) ?

However, I think such service doesn't exist for the lyx
mailing lists! If so, why not?

Rob.

Re: Subscribe to devel-mailing-list without receiving emails. Possible?

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
 
 It seems to me that, if you are not a subscriber and send a message,
 all you have to do is send a confirmation to some daemon and then you
 will be 'whitelisted' and allowed to post.
 
 Did you try that?
 
 Rob However, I discovered that my emails do not arrive on the list,
 Rob unless I am subscribed, which will also deliver all list messages
 Rob to me by regular email.
 
 And you do not receive a message?

So I have now unsubscribed from the lyx-devel mailing list.
This is what happens, when I send a message as non-member:
1) I receive a message to reconfirm; so I reconfirm that.
2) I then receive a message that my original message is permitted for lyx-devel.
3) I do never see my message appear on the lyx-devel gname news server.

So, even for this very message, I have no idea whether and when it actually
makes it to the list, despite all the confirmation exchange.
I therefor send this email also to you personally.

Cheers,
Rob.

Re: Subscribe to devel-mailing-list without receiving emails. Possible?

[Rob Lahaye]

Rob Lahaye wrote:
 Jean-Marc Lasgouttes wrote:
 
It seems to me that, if you are not a subscriber and send a message,
all you have to do is send a confirmation to some daemon and then you
will be 'whitelisted' and allowed to post.

Did you try that?

Rob However, I discovered that my emails do not arrive on the list,
Rob unless I am subscribed, which will also deliver all list messages
Rob to me by regular email.

And you do not receive a message?
 
 
 So I have now unsubscribed from the lyx-devel mailing list.
 This is what happens, when I send a message as non-member:
 1) I receive a message to reconfirm; so I reconfirm that.
 2) I then receive a message that my original message is permitted for lyx-devel.
 3) I do never see my message appear on the lyx-devel gname news server.

Ah, false alarm, but there's apparently a little bug in the mailer system.
The very first email as non-member (which needs reconfirmation) will not
be forwarded to the gname news server.
However, after this action has put me on a whitelist, all consecutive
messages from me to the list, will appear on the gname news server.

So, it's only the very first one that won't be on gmane.
I suppose the reconfirmation exchange to have me on the whitelist, forgets
the on-hold email to also forward to gmane, or something like that.

Cheers,
Rob.

gmane news server subscriber problems with non-members

[Rob Lahaye]

Mate,

The gmane news server should monitor all messages delivered to the lyx list.

The following appears to be a small, but annoying bug in the communication
between gmane news server and lyx lists (well, I only verified it with the
lyx-devel list):
As a non-member of the list, the very first email needs to be verified and confirmed.
But after reconfimation, the email will not be forwarded to the gname news server.
However, after this action has put me on a whitelist, all consecutive messages from me
to the list, will appear on the gname news server.
So, it's only the very first one that won't be on gmane.
I suppose the reconfirmation exchange to have me on the whitelist, forgets
the on-hold email to also forward to gmane, or something like that.
This is really a problem for peole (like me), who do a single test email first,
realize it is not working (the test email doesn't appear on gmane) and then
give up on it. Not realizing a next email actually would work as expected!
Is this easy to fix?

Regards,
Rob.

Re: Subscribe to devel-mailing-list without receiving emails. Possible?

[Rob Lahaye]

Rob Lahaye wrote:
Is there a way that allows me to send emails to the devel-list, but
that will not send all lyx-devel emails to my subscription address?
Jean-Marc Lasgouttes wrote:
> It seems to me that, if you are not a subscriber and send a message,
> all you have to do is send a confirmation to some daemon and then you
> will be 'whitelisted' and allowed to post.
>
> Did you try that?
Oh, maybe I tried once and considered the "confirmation" rather as a rejection.

Angus Leeming wrote:
Subscribe to the service and the mails that you receive telling you 
what step to take to confirm the subscription etc will also tell you 
where to find the web page that provides access to your mail delivery 
preferences. Go there and select the "do not receive mail" check box.
Here is what I got, after subscribing, which doesn't tell me
any webpage for making changes:
---
Hi! This is the ezmlm program. I'm managing the
[EMAIL PROTECTED] mailing list.
Acknowledgment: I have added the address

   [EMAIL PROTECTED]

to the lyx-devel mailing list.

Welcome to [EMAIL PROTECTED]

Please save this message so that you know the address you are
subscribed under, in case you later want to unsubscribe or change your
subscription address.
--- Administrative commands for the lyx-devel list ---

I can handle administrative requests automatically. Please
DO NOT SEND THEM TO THE LIST ADDRESS! If you do, I will not
see them and other subscribers will be annoyed. Instead, send
your message to the correct command address:
To subscribe to the list, send a message to:
   <[EMAIL PROTECTED]>
To remove your address from the list, send a message to:
   <[EMAIL PROTECTED]>
Similar addresses exist for the digest list:
   <[EMAIL PROTECTED]>
   <[EMAIL PROTECTED]>
To get messages 123 through 145 (a maximum of 100 per request), mail:
   <[EMAIL PROTECTED]>
To get an index with subject and author for messages 123-456 , mail:
   <[EMAIL PROTECTED]>
They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.
To get an index with subject and author for the last 100-200
messages (this also tells you the latest message number), mail:
   <[EMAIL PROTECTED]>
To receive all messages with the same subject as message 12345,
send an empty message to:
   <[EMAIL PROTECTED]>
The messages do not really need to be empty, but I will ignore
their content. Only the ADDRESS you send to is important.
You can start a subscription for an alternate address,
for example "[EMAIL PROTECTED]", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<[EMAIL PROTECTED]>
To stop subscription for this address, mail:
<[EMAIL PROTECTED]>
In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.
If despite following these instructions, you do not get the
desired results, please contact my owner at
[EMAIL PROTECTED] Please be patient, my owner is a
lot slower than I am
--- Enclosed is a copy of the request I received.

Re: Subscribe to devel-mailing-list without receiving emails. Possible?

[Rob Lahaye]

Angus Leeming wrote:
> Rob Lahaye wrote:
> 
>>Here is what I got, after subscribing, which doesn't tell me
>>any webpage for making changes:
> 
> 
> My apologies then.
> 
> What happens when you send a mail to 
> [EMAIL PROTECTED] for a help message?

Not useful either.

If you recommend me to visit certain webpage for this,
why not you tell me the webpage directly :) ?

However, I think such service doesn't exist for the lyx
mailing lists! If so, why not?

Rob.

Re: Subscribe to devel-mailing-list without receiving emails. Possible?

[Rob Lahaye]

Jean-Marc Lasgouttes wrote:
> 
> It seems to me that, if you are not a subscriber and send a message,
> all you have to do is send a confirmation to some daemon and then you
> will be 'whitelisted' and allowed to post.
> 
> Did you try that?
> 
> Rob> However, I discovered that my emails do not arrive on the list,
> Rob> unless I am subscribed, which will also deliver all list messages
> Rob> to me by regular email.
> 
> And you do not receive a message?

So I have now unsubscribed from the lyx-devel mailing list.
This is what happens, when I send a message as non-member:
1) I receive a message to reconfirm; so I reconfirm that.
2) I then receive a message that my original message is permitted for lyx-devel.
3) I do never see my message appear on the lyx-devel gname news server.

So, even for this very message, I have no idea whether and when it actually
makes it to the list, despite all the confirmation exchange.
I therefor send this email also to you personally.

Cheers,
Rob.