Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

 Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:

Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?

What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.

JMarc

Re: absolute path and graphics file

[Marcin Bukat]

Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:


Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc


Hmm. I see the same bug in xforms version. If included file is in 
'parent directory' path is absolute.

Regards
wo

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

 Marcin == Marcin Bukat [EMAIL PROTECTED] writes:

Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.

The algorithm used currently is:

* compute the included file path relative to the document path

* if this relative path starts with ../, use an absolute path
  instead.

The idea is that paths that are upper than the document are not likely
to be moved at the same time as the document. If you want to call that
a bug, you have to propose a better algorithm...

And of course the user can always override this choice.

JMarc

Re: absolute path and graphics file

[Marcin Bukat]

Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Marcin == Marcin Bukat [EMAIL PROTECTED] writes:


Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.
The algorithm used currently is:

* compute the included file path relative to the document path

* if this relative path starts with ../, use an absolute path
  instead.
The idea is that paths that are upper than the document are not likely
to be moved at the same time as the document. If you want to call that
a bug, you have to propose a better algorithm...
And of course the user can always override this choice.

JMarc
I would say it unconsequent behavior thats all.
What about adding switch 'always use relative path' to prefferences?
Regards
wo

Re: absolute path and graphics file

[Guanglei Cui]

However, what I experienced is that the absolute path is used even if the 
included files are in the same directory as the lyx file, which is my case 
and I started lyx always in the directory where the lyx file lives. 

Regards,

On Tuesday 01 July 2003 04:52, Jean-Marc Lasgouttes wrote:
  Marcin == Marcin Bukat [EMAIL PROTECTED] writes:

 Marcin Hmm. I see the same bug in xforms version. If included file is
 Marcin in 'parent directory' path is absolute.

 The algorithm used currently is:

 * compute the included file path relative to the document path

 * if this relative path starts with ../, use an absolute path
   instead.

 The idea is that paths that are upper than the document are not likely
 to be moved at the same time as the document. If you want to call that
 a bug, you have to propose a better algorithm...

 And of course the user can always override this choice.

 JMarc

-- 
Guanglei Cui
Dept. of Chemistry
SUNY at Stony Brook
Stony Brook, NY 11790

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

 Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:

Guanglei However, what I experienced is that the absolute path is
Guanglei used even if the included files are in the same directory as
Guanglei the lyx file, which is my case and I started lyx always in
Guanglei the directory where the lyx file lives.

This particular thing is probably bug 1028
http://bugzilla.lyx.org/show_bug.cgi?id=1028

It will be fixed in 1.3.3.

Now, if you are not using the qt port, then it is something else :)

JMarc

Re: absolute path and graphics file

[Guanglei Cui]

Thanks for all the reply. I do use qt lyx. 

On Tuesday 01 July 2003 09:20, Jean-Marc Lasgouttes wrote:
  Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:

 Guanglei However, what I experienced is that the absolute path is
 Guanglei used even if the included files are in the same directory as
 Guanglei the lyx file, which is my case and I started lyx always in
 Guanglei the directory where the lyx file lives.

 This particular thing is probably bug 1028
 http://bugzilla.lyx.org/show_bug.cgi?id=1028

 It will be fixed in 1.3.3.

 Now, if you are not using the qt port, then it is something else :)

 JMarc

-- 
Guanglei Cui
Dept. of Chemistry
SUNY at Stony Brook
Stony Brook, NY 11790

Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Hi all,

I'm not subscribed to lyx-dev and I just have already too many email lists. 
But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
figured I'd add a bit of info in case it helps the developers.

Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
rpms.

Crash mode: start new document, press Alt-I-S (insert special character).  The 
'Special' menu entry does NOT get highlighted, as it should.  Now, press right 
arrow.  Lyx crashes.

I tried it under gdb, and when lyx dies, everything seems to lock up, 
including the window manager.  But there's a way to recover: type Ctrl-Alt-F1, 
log into a text terminal, and kill the gdb process by hand.  Then type Alt-F7 
to go back to X.  The system is now unfrozen.

The following is a screen copy of the gdb output:

[~] gdb lyx
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-redhat-linux...(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/lyx
[New Thread 16384 (LWP 17855)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17855)]
0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
/usr/lib/qt-3.1/lib/libqt-mt.so.3
(gdb) Killed

lyx: SIGHUP signal caught
Bye.
[~] Mutex destroy failure: Device or resource busy


This crash is 100% reproducible.

I hope this is of some use.

Best,

f.

Re: Some info about lyx-qt 1.3.2 segfaults

[Matej Cepl]

On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
 Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
 rpms.

I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
on my computer.

This is the end of gdb story:

(no debugging symbols found)...(no debugging symbols found)...[New\
Cannot find thread 2049: invalid thread handle
(gdb)
lyx: SIGHUP signal caught
Ukonen (SIGTERM)
~$ Bye.

 This crash is 100% reproducible.

Sure it is.

 I hope this is of some use.

Me too.

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

Fernando Perez wrote:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 16384 (LWP 17855)]
 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from
 /usr/lib/qt-3.1/lib/libqt-mt.so.3
 (gdb) Killed
 
 lyx: SIGHUP signal caught
 Bye.
 [~] Mutex destroy failure: Device or resource busy

Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps. 

Regards, Alfredo

Re: Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Alfredo Braunstein wrote:

Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps. 
Under Gnome it's even a bit worse: after killing gdb and reentering X, the 
mouse pointer disappears! Hitting Alt-F1 to get a keyboard menu seems to 
resucitate the pointer.

Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms 
have no debugging info in them.  Sorry, but I don't have time right now to 
make a debug build and play with it.  If I make lyx dump core and try to load 
the core into gdb, the backtrace is pretty uninformative:

(gdb) core core.18511
Core was generated by `lyx'.
Program terminated with signal 6, Aborted.
#0  0x42028851 in ?? ()
(gdb) bt full
#0  0x42028851 in ?? ()
No symbol table info available.
#1  0x420284f4 in ?? ()
No symbol table info available.
#2  0x42029beb in ?? ()
No symbol table info available.
... more of the same (19 stack frames total) ...

Sorry for not being able to work more on this one.

Best,

f.

Re: Index question

[James Frye]

On Tue, 1 Jul 2003, Robin Turner wrote:

 or
 
 simulacra - see simulacrum
 simulacrum, 6, 8, 16

A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index.  I would love to have an option in the index
generator that says A and B are equivalent, so both A and B get a list of
the references to either.

James 

Re: Some info about lyx-qt 1.3.2 segfaults

[Andre Berger]

--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Matej Cepl [EMAIL PROTECTED], 2003-07-01 14:22 -0400:
 On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
  Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org su=
pplied=20
  rpms.
=20
 I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
 on my computer.
[...]
  This crash is 100% reproducible.
=20
 Sure it is.

Then again it works for me (doesn't crash when I do what the OP did):

[EMAIL PROTECTED]:~$ lyx --version
LyX 1.3.2 of Tue, May 6 2003
Built on May 12 2003, 15:27:38
Configuration
  Host type:  i686-pc-linux-gnu
  Special build flags:use-pspell
  C   Compiler:   gcc
  C   Compiler flags: -g -O2
  C++ Compiler:   g++ (2.95.4)
  C++ Compiler flags: -O2 -Wno-non-template-friend -ftemplate-d=
epth-30
  Linker flags:  =20
  Frontend:   qt
Qt version:   3.0.3=20
  LyX binary dir: /usr/bin
  LyX files dir:  /usr/share/lyx

Also self-compiled on Debian (woody w/ Adrian Bunk's additions).=20

-Andre

--NMuMz9nt05w80d4+
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Ad3cmlbrvn+0waMRAqokAJwKj6VUTWZmaneptT0AqYMcNPU/AACgtUQC
xrLx+g0rZ+WjMXa0EcLTHzU=
=Cu8v
-END PGP SIGNATURE-

--NMuMz9nt05w80d4+--

Re: Index question

[Robin Turner]

James Frye wrote:
On Tue, 1 Jul 2003, Robin Turner wrote:


or

simulacra - see simulacrum
simulacrum, 6, 8, 16


A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index.  I would love to have an option in the index
generator that says A and B are equivalent, so both A and B get a list of
the references to either.
I agree, but I can't see a way to do it in makeindex. Having said that ...

The single and most annoying thing anyone can do in an index is not 
provide an index.  Call me anal retentive, but I even want an index in a 
novel.

Robin

--
A strategy is still being formulated.
Robin Turner
IDMYO
Bilkent Univeritesi
Ankara 06533
Turkey
www.bilkent.edu.tr/~robin

Re: Some info about lyx-qt 1.3.2 segfaults

[larry]

Yes, Fernando.  I experience the same failure, and posted the exact same screen
copy of gdb output to the lyx-devel list last Friday.  I can't get my
environment to survive the crash either, but ONLY under gdb, oddly.

No one has offered up an answer, and others suggest everything works the right
way.  Someone suggested that my build might be on top of incompatible libraries
and includes, but did not suggest how to investigate this.

More broadly, the failure occurs whenever trying to access a submenu using
keyboard shortcuts, under qt.

I'm using Redhat 9, kde/qt 3.1.2.  Failure under my own builds and circulating
rh9 rpms for lyx 1.3.2.

On Tue, Jul 01, 2003 at 11:52:16AM -0600, Fernando Perez wrote:
 Hi all,
 
 I'm not subscribed to lyx-dev and I just have already too many email lists. 
 But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
 figured I'd add a bit of info in case it helps the developers.
 
 Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org 
 supplied rpms.
 
 Crash mode: start new document, press Alt-I-S (insert special character).  
 The 'Special' menu entry does NOT get highlighted, as it should.  Now, 
 press right arrow.  Lyx crashes.
 
 I tried it under gdb, and when lyx dies, everything seems to lock up, 
 including the window manager.  But there's a way to recover: type 
 Ctrl-Alt-F1, log into a text terminal, and kill the gdb process by hand.  
 Then type Alt-F7 to go back to X.  The system is now unfrozen.
 
 The following is a screen copy of the gdb output:
 
 [~] gdb lyx
 GNU gdb Red Hat Linux (5.2.1-4)
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-redhat-linux...(no debugging symbols 
 found)...
 (gdb) run
 Starting program: /usr/bin/lyx
 [New Thread 16384 (LWP 17855)]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 16384 (LWP 17855)]
 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
 /usr/lib/qt-3.1/lib/libqt-mt.so.3
 (gdb) Killed
 
 lyx: SIGHUP signal caught
 Bye.
 [~] Mutex destroy failure: Device or resource busy
 
 
 
 This crash is 100% reproducible.
 
 I hope this is of some use.
 
 Best,
 
 f.

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

[EMAIL PROTECTED] wrote:

 way.  Someone suggested that my build might be on top of incompatible
 libraries and includes, but did not suggest how to investigate this.

It seems that we have to discard this, since you (and others) get the same
with the precompiled version/with standard systems. 

 More broadly, the failure occurs whenever trying to access a submenu using
 keyboard shortcuts, under qt.
 
 I'm using Redhat 9, kde/qt 3.1.2.  Failure under my own builds and
 circulating rh9 rpms for lyx 1.3.2.

I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.

Regards, Alfredo

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

Fernando Perez wrote:

 Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms
 have no debugging info in them.  Sorry, but I don't have time right now to

Ah yes, forgot about that. 

Thanks anyway, Alfredo

backtrace on qt menu fails

[larry]

- Forwarded message from [EMAIL PROTECTED] -

From: [EMAIL PROTECTED]
Date: Tue, 1 Jul 2003 13:26:09 -0700
To: Alfredo Braunstein [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Really, nothing further on qt menu fails?

On Tue, Jul 01, 2003 at 08:25:26PM +0200, Alfredo Braunstein wrote:
 You may need to issue 
 ulimit -c unlimited
 to enable core dumps. 
 
 Then do
 gdb core.PID lyx
 and then please post the output of 'bt' to the list.

Alfredo: 

Thanks for the brief tutorial.

Here is the bt:

(gdb) bt
#0  0xe002 in ?? ()
#1  0x42028b93 in abort () from /lib/tls/libc.so.6
#2  0x082bb7a3 in lyx::abort() ()
#3  0x080d5c11 in error_handler ()
#4  signal handler called
#5  0x4031eef6 in QPopupMenu::keyPressEvent(QKeyEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#6  0x40288532 in QWidget::event(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#7  0x402141d3 in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#8  0x40213e43 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3#9  0x401cccf3 in 
QETWidget::translateKeyEvent(_XEvent const*, bool) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#10 0x401c9738 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#11 0x401da8c4 in QEventLoop::processEvents(unsigned) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#12 0x40223ef5 in QEventLoop::enterLoop() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#13 0x40223dc7 in QEventLoop::exec() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#14 0x40214386 in QApplication::exec() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#15 0x0821a0ab in lyx_gui::start(std::string const, std::vectorstd::string, 
std::allocatorstd::string  const) ()
#16 0x080d5a48 in LyX::LyX(int, char**) ()
#17 0x081060a5 in main ()
#18 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) ~

Again, this occurs with any use of keyboard shortcuts to access a submenu item,
like Edit- Special Character   - HFill the commands
  OK - Item not highlighted- CRASH the result

- End forwarded message -

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[John Levon]

On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:

  /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
  types for `typedef struct OpaqueControlRef * ControlRef'
  ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
  `class ControlRef'
 
 As far as I understand it, this is a naming clash. Qt has a 
 typedef struct OpaqueControlRef *ControlRef;

Has anyone reported this stupid bug to Troll Tech yet ?

regards
john

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

John Levon [EMAIL PROTECTED] writes:

 On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
 
   /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
   types for `typedef struct OpaqueControlRef * ControlRef'
   ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
   `class ControlRef'
  
  As far as I understand it, this is a naming clash. Qt has a 
  typedef struct OpaqueControlRef *ControlRef;
 
 Has anyone reported this stupid bug to Troll Tech yet ?

The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
-- 

Ronald Florence www.18james.com

Re: Some info about lyx-qt 1.3.2 segfaults

[Matej Cepl]

On 2003-07-01, 20:42 GMT, Alfredo Braunstein wrote:
 way.  Someone suggested that my build might be on top of incompatible
 libraries and includes, but did not suggest how to investigate this.
 
 It seems that we have to discard this, since you (and others) get the same
 with the precompiled version/with standard systems. 

Just to note, that my system is not standard (using additional KDE from
debian.kde.org).

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: 
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous 
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef struct OpaqueControlRef *ControlRef;
Has anyone reported this stupid bug to Troll Tech yet ?
The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
I do not agree upon the statement that Trolltech is not interested in 
supporting
and  bug reports on QT/Aqua ! In fact, I think the opposite is the 
case: they want
open source programmers to report their bugs so that they can finally
solve most of them - thats why they released QT/Aqua under GPL in the 
first
place!

I suggest we send them every bug we find! And: whenever I asked them for
help, they responded so far!
Jan

Re: Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Alfredo Braunstein wrote:

I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.
More specifically (in case it helps you guys), I'm using RedHat 8.0, but I 
updated my qt/kde from freshrpms.org to:

kdelibs-3.1.2-0.fdr.3.rh80
qt-3.1.2-7.fdr.0.rh80
My Lyx is from lyx.org:

lyx-1.3.2-1_qt

Again, sorry I can't do deeper debugging here.

Best,

f.

Re: Some info about lyx-qt 1.3.2

[John Sheahan]

Hi Fernando

my computer is currently rh8.0 [1] with all current redhat updates.
Using a locally compiled lyx qt binary , does NOT crash following your
procedure.
Note my qt libs are older than yours.

 [EMAIL PROTECTED] john]$ ldd `which lyx`
libqt-mt.so.3 = /usr/lib/qt-3.0.5/lib/libqt-mt.so.3
(0x40028000)
libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x40657000)
libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x4066)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40677000)
libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x40755000)
libm.so.6 = /lib/i686/libm.so.6 (0x40807000)
libc.so.6 = /lib/i686/libc.so.6 (0x4200)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x4082a000)
libpthread.so.0 = /lib/i686/libpthread.so.0 (0x40832000)
libcups.so.2 = /usr/lib/libcups.so.2 (0x40882000)
libmng.so.1 = /usr/lib/libmng.so.1 (0x4089c000)
libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x408e)
libpng12.so.0 = /usr/lib/libpng12.so.0 (0x408fe000)
libz.so.1 = /usr/lib/libz.so.1 (0x40922000)
libGL.so.1 = /usr/lib/libGL.so.1 (0x4093)
libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x409a3000)
libdl.so.2 = /lib/libdl.so.2 (0x409b9000)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x409bc000)
libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x409ca000)
libXft.so.2 = /usr/lib/libXft.so.2 (0x409d)
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0x409e2000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
libssl.so.2 = /lib/libssl.so.2 (0x40a07000)
libcrypto.so.2 = /lib/libcrypto.so.2 (0x40a37000)
libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x40b0b000)
libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x40b5e000)
libexpat.so.0 = /usr/lib/libexpat.so.0 (0x40ba7000)


[1] xinerama on rh9's XFree86 4.3 is too unstable with a matrox G450 to
use. If you have not used xinerama on 2 monitors, I suggest you don't, 
as its impossible to go back.  Disabling x font render helps some. 

john



On Wed, 2003-07-02 at 03:52, Fernando Perez wrote:
 Hi all,
 
 I'm not subscribed to lyx-dev and I just have already too many email lists. 
 But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
 figured I'd add a bit of info in case it helps the developers.
 
 Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
 rpms.
 
 Crash mode: start new document, press Alt-I-S (insert special character).  The 
 'Special' menu entry does NOT get highlighted, as it should.  Now, press right 
 arrow.  Lyx crashes.
 
 I tried it under gdb, and when lyx dies, everything seems to lock up, 
 including the window manager.  But there's a way to recover: type Ctrl-Alt-F1, 
 log into a text terminal, and kill the gdb process by hand.  Then type Alt-F7 
 to go back to X.  The system is now unfrozen.
 
 The following is a screen copy of the gdb output:
 
 [~] gdb lyx
 GNU gdb Red Hat Linux (5.2.1-4)
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-redhat-linux...(no debugging symbols found)...
 (gdb) run
 Starting program: /usr/bin/lyx
 [New Thread 16384 (LWP 17855)]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 16384 (LWP 17855)]
 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
 /usr/lib/qt-3.1/lib/libqt-mt.so.3
 (gdb) Killed
 
 lyx: SIGHUP signal caught
 Bye.
 [~] Mutex destroy failure: Device or resource busy
 
 
 
 This crash is 100% reproducible.
 
 I hope this is of some use.
 
 Best,
 
 f.

Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

I mailed Trolltech about the discussion, and there reply is:

I agree, you can safely remove it from qwindowdefs.h. Originally it was
thought to be necessary for future plans, but not.
However, using ControlRef might be a bad idea in any event as it is a
type in Carbon so including some headers could indeed pull it in
otherwise.
Regards
//Sam

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

 Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:

Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?

What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.

JMarc

Re: absolute path and graphics file

[Marcin Bukat]

Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:


Guanglei Thanks, but can this be automatic? Can this be done through
Guanglei working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc


Hmm. I see the same bug in xforms version. If included file is in 
'parent directory' path is absolute.

Regards
wo

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

 Marcin == Marcin Bukat [EMAIL PROTECTED] writes:

Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.

The algorithm used currently is:

* compute the included file path relative to the document path

* if this relative path starts with ../, use an absolute path
  instead.

The idea is that paths that are upper than the document are not likely
to be moved at the same time as the document. If you want to call that
a bug, you have to propose a better algorithm...

And of course the user can always override this choice.

JMarc

Re: absolute path and graphics file

[Marcin Bukat]

Uz.ytkownik Jean-Marc Lasgouttes napisa?:
Marcin == Marcin Bukat [EMAIL PROTECTED] writes:


Marcin Hmm. I see the same bug in xforms version. If included file is
Marcin in 'parent directory' path is absolute.
The algorithm used currently is:

* compute the included file path relative to the document path

* if this relative path starts with ../, use an absolute path
  instead.
The idea is that paths that are upper than the document are not likely
to be moved at the same time as the document. If you want to call that
a bug, you have to propose a better algorithm...
And of course the user can always override this choice.

JMarc
I would say it unconsequent behavior thats all.
What about adding switch 'always use relative path' to prefferences?
Regards
wo

Re: absolute path and graphics file

[Guanglei Cui]

However, what I experienced is that the absolute path is used even if the 
included files are in the same directory as the lyx file, which is my case 
and I started lyx always in the directory where the lyx file lives. 

Regards,

On Tuesday 01 July 2003 04:52, Jean-Marc Lasgouttes wrote:
  Marcin == Marcin Bukat [EMAIL PROTECTED] writes:

 Marcin Hmm. I see the same bug in xforms version. If included file is
 Marcin in 'parent directory' path is absolute.

 The algorithm used currently is:

 * compute the included file path relative to the document path

 * if this relative path starts with ../, use an absolute path
   instead.

 The idea is that paths that are upper than the document are not likely
 to be moved at the same time as the document. If you want to call that
 a bug, you have to propose a better algorithm...

 And of course the user can always override this choice.

 JMarc

-- 
Guanglei Cui
Dept. of Chemistry
SUNY at Stony Brook
Stony Brook, NY 11790

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

 Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:

Guanglei However, what I experienced is that the absolute path is
Guanglei used even if the included files are in the same directory as
Guanglei the lyx file, which is my case and I started lyx always in
Guanglei the directory where the lyx file lives.

This particular thing is probably bug 1028
http://bugzilla.lyx.org/show_bug.cgi?id=1028

It will be fixed in 1.3.3.

Now, if you are not using the qt port, then it is something else :)

JMarc

Re: absolute path and graphics file

[Guanglei Cui]

Thanks for all the reply. I do use qt lyx. 

On Tuesday 01 July 2003 09:20, Jean-Marc Lasgouttes wrote:
  Guanglei == Guanglei Cui [EMAIL PROTECTED] writes:

 Guanglei However, what I experienced is that the absolute path is
 Guanglei used even if the included files are in the same directory as
 Guanglei the lyx file, which is my case and I started lyx always in
 Guanglei the directory where the lyx file lives.

 This particular thing is probably bug 1028
 http://bugzilla.lyx.org/show_bug.cgi?id=1028

 It will be fixed in 1.3.3.

 Now, if you are not using the qt port, then it is something else :)

 JMarc

-- 
Guanglei Cui
Dept. of Chemistry
SUNY at Stony Brook
Stony Brook, NY 11790

Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Hi all,

I'm not subscribed to lyx-dev and I just have already too many email lists. 
But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
figured I'd add a bit of info in case it helps the developers.

Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
rpms.

Crash mode: start new document, press Alt-I-S (insert special character).  The 
'Special' menu entry does NOT get highlighted, as it should.  Now, press right 
arrow.  Lyx crashes.

I tried it under gdb, and when lyx dies, everything seems to lock up, 
including the window manager.  But there's a way to recover: type Ctrl-Alt-F1, 
log into a text terminal, and kill the gdb process by hand.  Then type Alt-F7 
to go back to X.  The system is now unfrozen.

The following is a screen copy of the gdb output:

[~] gdb lyx
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-redhat-linux...(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/lyx
[New Thread 16384 (LWP 17855)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17855)]
0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
/usr/lib/qt-3.1/lib/libqt-mt.so.3
(gdb) Killed

lyx: SIGHUP signal caught
Bye.
[~] Mutex destroy failure: Device or resource busy


This crash is 100% reproducible.

I hope this is of some use.

Best,

f.

Re: Some info about lyx-qt 1.3.2 segfaults

[Matej Cepl]

On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
 Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
 rpms.

I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
on my computer.

This is the end of gdb story:

(no debugging symbols found)...(no debugging symbols found)...[New\
Cannot find thread 2049: invalid thread handle
(gdb)
lyx: SIGHUP signal caught
Ukonen (SIGTERM)
~$ Bye.

 This crash is 100% reproducible.

Sure it is.

 I hope this is of some use.

Me too.

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

Fernando Perez wrote:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 16384 (LWP 17855)]
 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from
 /usr/lib/qt-3.1/lib/libqt-mt.so.3
 (gdb) Killed
 
 lyx: SIGHUP signal caught
 Bye.
 [~] Mutex destroy failure: Device or resource busy

Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps. 

Regards, Alfredo

Re: Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Alfredo Braunstein wrote:

Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps. 
Under Gnome it's even a bit worse: after killing gdb and reentering X, the 
mouse pointer disappears! Hitting Alt-F1 to get a keyboard menu seems to 
resucitate the pointer.

Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms 
have no debugging info in them.  Sorry, but I don't have time right now to 
make a debug build and play with it.  If I make lyx dump core and try to load 
the core into gdb, the backtrace is pretty uninformative:

(gdb) core core.18511
Core was generated by `lyx'.
Program terminated with signal 6, Aborted.
#0  0x42028851 in ?? ()
(gdb) bt full
#0  0x42028851 in ?? ()
No symbol table info available.
#1  0x420284f4 in ?? ()
No symbol table info available.
#2  0x42029beb in ?? ()
No symbol table info available.
... more of the same (19 stack frames total) ...

Sorry for not being able to work more on this one.

Best,

f.

Re: Index question

[James Frye]

On Tue, 1 Jul 2003, Robin Turner wrote:

 or
 
 simulacra - see simulacrum
 simulacrum, 6, 8, 16

A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index.  I would love to have an option in the index
generator that says A and B are equivalent, so both A and B get a list of
the references to either.

James 

Re: Some info about lyx-qt 1.3.2 segfaults

[Andre Berger]

--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Matej Cepl [EMAIL PROTECTED], 2003-07-01 14:22 -0400:
 On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
  Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org su=
pplied=20
  rpms.
=20
 I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
 on my computer.
[...]
  This crash is 100% reproducible.
=20
 Sure it is.

Then again it works for me (doesn't crash when I do what the OP did):

[EMAIL PROTECTED]:~$ lyx --version
LyX 1.3.2 of Tue, May 6 2003
Built on May 12 2003, 15:27:38
Configuration
  Host type:  i686-pc-linux-gnu
  Special build flags:use-pspell
  C   Compiler:   gcc
  C   Compiler flags: -g -O2
  C++ Compiler:   g++ (2.95.4)
  C++ Compiler flags: -O2 -Wno-non-template-friend -ftemplate-d=
epth-30
  Linker flags:  =20
  Frontend:   qt
Qt version:   3.0.3=20
  LyX binary dir: /usr/bin
  LyX files dir:  /usr/share/lyx

Also self-compiled on Debian (woody w/ Adrian Bunk's additions).=20

-Andre

--NMuMz9nt05w80d4+
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Ad3cmlbrvn+0waMRAqokAJwKj6VUTWZmaneptT0AqYMcNPU/AACgtUQC
xrLx+g0rZ+WjMXa0EcLTHzU=
=Cu8v
-END PGP SIGNATURE-

--NMuMz9nt05w80d4+--

Re: Index question

[Robin Turner]

James Frye wrote:
On Tue, 1 Jul 2003, Robin Turner wrote:


or

simulacra - see simulacrum
simulacrum, 6, 8, 16


A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index.  I would love to have an option in the index
generator that says A and B are equivalent, so both A and B get a list of
the references to either.
I agree, but I can't see a way to do it in makeindex. Having said that ...

The single and most annoying thing anyone can do in an index is not 
provide an index.  Call me anal retentive, but I even want an index in a 
novel.

Robin

--
A strategy is still being formulated.
Robin Turner
IDMYO
Bilkent Univeritesi
Ankara 06533
Turkey
www.bilkent.edu.tr/~robin

Re: Some info about lyx-qt 1.3.2 segfaults

[larry]

Yes, Fernando.  I experience the same failure, and posted the exact same screen
copy of gdb output to the lyx-devel list last Friday.  I can't get my
environment to survive the crash either, but ONLY under gdb, oddly.

No one has offered up an answer, and others suggest everything works the right
way.  Someone suggested that my build might be on top of incompatible libraries
and includes, but did not suggest how to investigate this.

More broadly, the failure occurs whenever trying to access a submenu using
keyboard shortcuts, under qt.

I'm using Redhat 9, kde/qt 3.1.2.  Failure under my own builds and circulating
rh9 rpms for lyx 1.3.2.

On Tue, Jul 01, 2003 at 11:52:16AM -0600, Fernando Perez wrote:
 Hi all,
 
 I'm not subscribed to lyx-dev and I just have already too many email lists. 
 But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
 figured I'd add a bit of info in case it helps the developers.
 
 Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org 
 supplied rpms.
 
 Crash mode: start new document, press Alt-I-S (insert special character).  
 The 'Special' menu entry does NOT get highlighted, as it should.  Now, 
 press right arrow.  Lyx crashes.
 
 I tried it under gdb, and when lyx dies, everything seems to lock up, 
 including the window manager.  But there's a way to recover: type 
 Ctrl-Alt-F1, log into a text terminal, and kill the gdb process by hand.  
 Then type Alt-F7 to go back to X.  The system is now unfrozen.
 
 The following is a screen copy of the gdb output:
 
 [~] gdb lyx
 GNU gdb Red Hat Linux (5.2.1-4)
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-redhat-linux...(no debugging symbols 
 found)...
 (gdb) run
 Starting program: /usr/bin/lyx
 [New Thread 16384 (LWP 17855)]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 16384 (LWP 17855)]
 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
 /usr/lib/qt-3.1/lib/libqt-mt.so.3
 (gdb) Killed
 
 lyx: SIGHUP signal caught
 Bye.
 [~] Mutex destroy failure: Device or resource busy
 
 
 
 This crash is 100% reproducible.
 
 I hope this is of some use.
 
 Best,
 
 f.

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

[EMAIL PROTECTED] wrote:

 way.  Someone suggested that my build might be on top of incompatible
 libraries and includes, but did not suggest how to investigate this.

It seems that we have to discard this, since you (and others) get the same
with the precompiled version/with standard systems. 

 More broadly, the failure occurs whenever trying to access a submenu using
 keyboard shortcuts, under qt.
 
 I'm using Redhat 9, kde/qt 3.1.2.  Failure under my own builds and
 circulating rh9 rpms for lyx 1.3.2.

I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.

Regards, Alfredo

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

Fernando Perez wrote:

 Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms
 have no debugging info in them.  Sorry, but I don't have time right now to

Ah yes, forgot about that. 

Thanks anyway, Alfredo

backtrace on qt menu fails

[larry]

- Forwarded message from [EMAIL PROTECTED] -

From: [EMAIL PROTECTED]
Date: Tue, 1 Jul 2003 13:26:09 -0700
To: Alfredo Braunstein [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Really, nothing further on qt menu fails?

On Tue, Jul 01, 2003 at 08:25:26PM +0200, Alfredo Braunstein wrote:
 You may need to issue 
 ulimit -c unlimited
 to enable core dumps. 
 
 Then do
 gdb core.PID lyx
 and then please post the output of 'bt' to the list.

Alfredo: 

Thanks for the brief tutorial.

Here is the bt:

(gdb) bt
#0  0xe002 in ?? ()
#1  0x42028b93 in abort () from /lib/tls/libc.so.6
#2  0x082bb7a3 in lyx::abort() ()
#3  0x080d5c11 in error_handler ()
#4  signal handler called
#5  0x4031eef6 in QPopupMenu::keyPressEvent(QKeyEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#6  0x40288532 in QWidget::event(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#7  0x402141d3 in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#8  0x40213e43 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3#9  0x401cccf3 in 
QETWidget::translateKeyEvent(_XEvent const*, bool) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#10 0x401c9738 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#11 0x401da8c4 in QEventLoop::processEvents(unsigned) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#12 0x40223ef5 in QEventLoop::enterLoop() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#13 0x40223dc7 in QEventLoop::exec() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#14 0x40214386 in QApplication::exec() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#15 0x0821a0ab in lyx_gui::start(std::string const, std::vectorstd::string, 
std::allocatorstd::string  const) ()
#16 0x080d5a48 in LyX::LyX(int, char**) ()
#17 0x081060a5 in main ()
#18 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) ~

Again, this occurs with any use of keyboard shortcuts to access a submenu item,
like Edit- Special Character   - HFill the commands
  OK - Item not highlighted- CRASH the result

- End forwarded message -

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[John Levon]

On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:

  /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
  types for `typedef struct OpaqueControlRef * ControlRef'
  ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
  `class ControlRef'
 
 As far as I understand it, this is a naming clash. Qt has a 
 typedef struct OpaqueControlRef *ControlRef;

Has anyone reported this stupid bug to Troll Tech yet ?

regards
john

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

John Levon [EMAIL PROTECTED] writes:

 On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
 
   /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
   types for `typedef struct OpaqueControlRef * ControlRef'
   ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
   `class ControlRef'
  
  As far as I understand it, this is a naming clash. Qt has a 
  typedef struct OpaqueControlRef *ControlRef;
 
 Has anyone reported this stupid bug to Troll Tech yet ?

The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
-- 

Ronald Florence www.18james.com

Re: Some info about lyx-qt 1.3.2 segfaults

[Matej Cepl]

On 2003-07-01, 20:42 GMT, Alfredo Braunstein wrote:
 way.  Someone suggested that my build might be on top of incompatible
 libraries and includes, but did not suggest how to investigate this.
 
 It seems that we have to discard this, since you (and others) get the same
 with the precompiled version/with standard systems. 

Just to note, that my system is not standard (using additional KDE from
debian.kde.org).

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: 
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous 
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef struct OpaqueControlRef *ControlRef;
Has anyone reported this stupid bug to Troll Tech yet ?
The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
I do not agree upon the statement that Trolltech is not interested in 
supporting
and  bug reports on QT/Aqua ! In fact, I think the opposite is the 
case: they want
open source programmers to report their bugs so that they can finally
solve most of them - thats why they released QT/Aqua under GPL in the 
first
place!

I suggest we send them every bug we find! And: whenever I asked them for
help, they responded so far!
Jan

Re: Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Alfredo Braunstein wrote:

I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.
More specifically (in case it helps you guys), I'm using RedHat 8.0, but I 
updated my qt/kde from freshrpms.org to:

kdelibs-3.1.2-0.fdr.3.rh80
qt-3.1.2-7.fdr.0.rh80
My Lyx is from lyx.org:

lyx-1.3.2-1_qt

Again, sorry I can't do deeper debugging here.

Best,

f.

Re: Some info about lyx-qt 1.3.2

[John Sheahan]

Hi Fernando

my computer is currently rh8.0 [1] with all current redhat updates.
Using a locally compiled lyx qt binary , does NOT crash following your
procedure.
Note my qt libs are older than yours.

 [EMAIL PROTECTED] john]$ ldd `which lyx`
libqt-mt.so.3 = /usr/lib/qt-3.0.5/lib/libqt-mt.so.3
(0x40028000)
libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x40657000)
libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x4066)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40677000)
libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0x40755000)
libm.so.6 = /lib/i686/libm.so.6 (0x40807000)
libc.so.6 = /lib/i686/libc.so.6 (0x4200)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x4082a000)
libpthread.so.0 = /lib/i686/libpthread.so.0 (0x40832000)
libcups.so.2 = /usr/lib/libcups.so.2 (0x40882000)
libmng.so.1 = /usr/lib/libmng.so.1 (0x4089c000)
libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x408e)
libpng12.so.0 = /usr/lib/libpng12.so.0 (0x408fe000)
libz.so.1 = /usr/lib/libz.so.1 (0x40922000)
libGL.so.1 = /usr/lib/libGL.so.1 (0x4093)
libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x409a3000)
libdl.so.2 = /lib/libdl.so.2 (0x409b9000)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x409bc000)
libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x409ca000)
libXft.so.2 = /usr/lib/libXft.so.2 (0x409d)
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1 (0x409e2000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
libssl.so.2 = /lib/libssl.so.2 (0x40a07000)
libcrypto.so.2 = /lib/libcrypto.so.2 (0x40a37000)
libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x40b0b000)
libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x40b5e000)
libexpat.so.0 = /usr/lib/libexpat.so.0 (0x40ba7000)


[1] xinerama on rh9's XFree86 4.3 is too unstable with a matrox G450 to
use. If you have not used xinerama on 2 monitors, I suggest you don't, 
as its impossible to go back.  Disabling x font render helps some. 

john



On Wed, 2003-07-02 at 03:52, Fernando Perez wrote:
 Hi all,
 
 I'm not subscribed to lyx-dev and I just have already too many email lists. 
 But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
 figured I'd add a bit of info in case it helps the developers.
 
 Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
 rpms.
 
 Crash mode: start new document, press Alt-I-S (insert special character).  The 
 'Special' menu entry does NOT get highlighted, as it should.  Now, press right 
 arrow.  Lyx crashes.
 
 I tried it under gdb, and when lyx dies, everything seems to lock up, 
 including the window manager.  But there's a way to recover: type Ctrl-Alt-F1, 
 log into a text terminal, and kill the gdb process by hand.  Then type Alt-F7 
 to go back to X.  The system is now unfrozen.
 
 The following is a screen copy of the gdb output:
 
 [~] gdb lyx
 GNU gdb Red Hat Linux (5.2.1-4)
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-redhat-linux...(no debugging symbols found)...
 (gdb) run
 Starting program: /usr/bin/lyx
 [New Thread 16384 (LWP 17855)]
 
 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 16384 (LWP 17855)]
 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
 /usr/lib/qt-3.1/lib/libqt-mt.so.3
 (gdb) Killed
 
 lyx: SIGHUP signal caught
 Bye.
 [~] Mutex destroy failure: Device or resource busy
 
 
 
 This crash is 100% reproducible.
 
 I hope this is of some use.
 
 Best,
 
 f.

Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

I mailed Trolltech about the discussion, and there reply is:

I agree, you can safely remove it from qwindowdefs.h. Originally it was
thought to be necessary for future plans, but not.
However, using ControlRef might be a bad idea in any event as it is a
type in Carbon so including some headers could indeed pull it in
otherwise.
Regards
//Sam

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

> "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:

Guanglei> Thanks, but can this be automatic? Can this be done through
Guanglei> working directory setting?

What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.

JMarc

Re: absolute path and graphics file

[Marcin Bukat]

Uz.ytkownik Jean-Marc Lasgouttes napisa?:
"Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:


Guanglei> Thanks, but can this be automatic? Can this be done through
Guanglei> working directory setting?
What you are seeing is a bug in the qt frontend of LyX 1.3.2. It will be
fixed in 1.3.3.
JMarc


Hmm. I see the same bug in xforms version. If included file is in 
'parent directory' path is absolute.

Regards
wo

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

> "Marcin" == Marcin Bukat <[EMAIL PROTECTED]> writes:

Marcin> Hmm. I see the same bug in xforms version. If included file is
Marcin> in 'parent directory' path is absolute.

The algorithm used currently is:

* compute the included file path relative to the document path

* if this relative path starts with ../, use an absolute path
  instead.

The idea is that paths that are upper than the document are not likely
to be moved at the same time as the document. If you want to call that
a bug, you have to propose a better algorithm...

And of course the user can always override this choice.

JMarc

Re: absolute path and graphics file

[Marcin Bukat]

Uz.ytkownik Jean-Marc Lasgouttes napisa?:
"Marcin" == Marcin Bukat <[EMAIL PROTECTED]> writes:


Marcin> Hmm. I see the same bug in xforms version. If included file is
Marcin> in 'parent directory' path is absolute.
The algorithm used currently is:

* compute the included file path relative to the document path

* if this relative path starts with ../, use an absolute path
  instead.
The idea is that paths that are upper than the document are not likely
to be moved at the same time as the document. If you want to call that
a bug, you have to propose a better algorithm...
And of course the user can always override this choice.

JMarc
I would say it unconsequent behavior thats all.
What about adding switch 'always use relative path' to prefferences?
Regards
wo

Re: absolute path and graphics file

[Guanglei Cui]

However, what I experienced is that the absolute path is used even if the 
included files are in the same directory as the lyx file, which is my case 
and I started lyx always in the directory where the lyx file lives. 

Regards,

On Tuesday 01 July 2003 04:52, Jean-Marc Lasgouttes wrote:
> > "Marcin" == Marcin Bukat <[EMAIL PROTECTED]> writes:
>
> Marcin> Hmm. I see the same bug in xforms version. If included file is
> Marcin> in 'parent directory' path is absolute.
>
> The algorithm used currently is:
>
> * compute the included file path relative to the document path
>
> * if this relative path starts with ../, use an absolute path
>   instead.
>
> The idea is that paths that are upper than the document are not likely
> to be moved at the same time as the document. If you want to call that
> a bug, you have to propose a better algorithm...
>
> And of course the user can always override this choice.
>
> JMarc

-- 
Guanglei Cui
Dept. of Chemistry
SUNY at Stony Brook
Stony Brook, NY 11790

Re: absolute path and graphics file

[Jean-Marc Lasgouttes]

> "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:

Guanglei> However, what I experienced is that the absolute path is
Guanglei> used even if the included files are in the same directory as
Guanglei> the lyx file, which is my case and I started lyx always in
Guanglei> the directory where the lyx file lives.

This particular thing is probably bug 1028
http://bugzilla.lyx.org/show_bug.cgi?id=1028

It will be fixed in 1.3.3.

Now, if you are not using the qt port, then it is something else :)

JMarc

Re: absolute path and graphics file

[Guanglei Cui]

Thanks for all the reply. I do use qt lyx. 

On Tuesday 01 July 2003 09:20, Jean-Marc Lasgouttes wrote:
> > "Guanglei" == Guanglei Cui <[EMAIL PROTECTED]> writes:
>
> Guanglei> However, what I experienced is that the absolute path is
> Guanglei> used even if the included files are in the same directory as
> Guanglei> the lyx file, which is my case and I started lyx always in
> Guanglei> the directory where the lyx file lives.
>
> This particular thing is probably bug 1028
> http://bugzilla.lyx.org/show_bug.cgi?id=1028
>
> It will be fixed in 1.3.3.
>
> Now, if you are not using the qt port, then it is something else :)
>
> JMarc

-- 
Guanglei Cui
Dept. of Chemistry
SUNY at Stony Brook
Stony Brook, NY 11790

Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Hi all,

I'm not subscribed to lyx-dev and I just have already too many email lists. 
But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
figured I'd add a bit of info in case it helps the developers.

Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
rpms.

Crash mode: start new document, press Alt-I-S (insert special character).  The 
'Special' menu entry does NOT get highlighted, as it should.  Now, press right 
arrow.  Lyx crashes.

I tried it under gdb, and when lyx dies, everything seems to lock up, 
including the window manager.  But there's a way to recover: type Ctrl-Alt-F1, 
log into a text terminal, and kill the gdb process by hand.  Then type Alt-F7 
to go back to X.  The system is now unfrozen.

The following is a screen copy of the gdb output:

[~]> gdb lyx
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/lyx
[New Thread 16384 (LWP 17855)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 17855)]
0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
/usr/lib/qt-3.1/lib/libqt-mt.so.3
(gdb) Killed

lyx: SIGHUP signal caught
Bye.
[~]> Mutex destroy failure: Device or resource busy


This crash is 100% reproducible.

I hope this is of some use.

Best,

f.

Re: Some info about lyx-qt 1.3.2 segfaults

[Matej Cepl]

On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
> Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
> rpms.

I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
on my computer.

This is the end of gdb story:

(no debugging symbols found)...(no debugging symbols found)...[New\
Cannot find thread 2049: invalid thread handle
(gdb)
lyx: SIGHUP signal caught
Ukončen (SIGTERM)
~$ Bye.

> This crash is 100% reproducible.

Sure it is.

> I hope this is of some use.

Me too.

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

Fernando Perez wrote:

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 17855)]
> 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from
> /usr/lib/qt-3.1/lib/libqt-mt.so.3
> (gdb) Killed
> 
> lyx: SIGHUP signal caught
> Bye.
> [~]> Mutex destroy failure: Device or resource busy

Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps. 

Regards, Alfredo

Re: Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Alfredo Braunstein wrote:

Could you try to get a complete backtrace? Not running kde, or
enabling/using a core file maybe helps. 
Under Gnome it's even a bit worse: after killing gdb and reentering X, the 
mouse pointer disappears! Hitting Alt-F1 to get a keyboard menu seems to 
resucitate the pointer.

Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms 
have no debugging info in them.  Sorry, but I don't have time right now to 
make a debug build and play with it.  If I make lyx dump core and try to load 
the core into gdb, the backtrace is pretty uninformative:

(gdb) core core.18511
Core was generated by `lyx'.
Program terminated with signal 6, Aborted.
#0  0x42028851 in ?? ()
(gdb) bt full
#0  0x42028851 in ?? ()
No symbol table info available.
#1  0x420284f4 in ?? ()
No symbol table info available.
#2  0x42029beb in ?? ()
No symbol table info available.
... more of the same (19 stack frames total) ...

Sorry for not being able to work more on this one.

Best,

f.

Re: Index question

[James Frye]

On Tue, 1 Jul 2003, Robin Turner wrote:

> or
> 
> simulacra - see simulacrum
> simulacrum, 6, 8, 16

A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index.  I would love to have an option in the index
generator that says A and B are equivalent, so both A and B get a list of
the references to either.

James 

Re: Some info about lyx-qt 1.3.2 segfaults

[Andre Berger]

--NMuMz9nt05w80d4+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Matej Cepl <[EMAIL PROTECTED]>, 2003-07-01 14:22 -0400:
> On 2003-07-01, 17:52 GMT, Fernando Perez wrote:
> > Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org su=
pplied=20
> > rpms.
>=20
> I've got the same with Debian 3.0, KDE 3.1.2, LyX 1.3.2 compiled by hand
> on my computer.
[...]
> > This crash is 100% reproducible.
>=20
> Sure it is.

Then again it works for me (doesn't crash when I do what the OP did):

[EMAIL PROTECTED]:~$ lyx --version
LyX 1.3.2 of Tue, May 6 2003
Built on May 12 2003, 15:27:38
Configuration
  Host type:  i686-pc-linux-gnu
  Special build flags:use-pspell
  C   Compiler:   gcc
  C   Compiler flags: -g -O2
  C++ Compiler:   g++ (2.95.4)
  C++ Compiler flags: -O2 -Wno-non-template-friend -ftemplate-d=
epth-30
  Linker flags:  =20
  Frontend:   qt
Qt version:   3.0.3=20
  LyX binary dir: /usr/bin
  LyX files dir:  /usr/share/lyx

Also self-compiled on Debian (woody w/ Adrian Bunk's additions).=20

-Andre

--NMuMz9nt05w80d4+
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Ad3cmlbrvn+0waMRAqokAJwKj6VUTWZmaneptT0AqYMcNPU/AACgtUQC
xrLx+g0rZ+WjMXa0EcLTHzU=
=Cu8v
-END PGP SIGNATURE-

--NMuMz9nt05w80d4+--

Re: Index question

[Robin Turner]

James Frye wrote:
On Tue, 1 Jul 2003, Robin Turner wrote:


or

simulacra - see simulacrum
simulacrum, 6, 8, 16


A bit off the track, but IMHO this is the single most annoying thing
anyone can do in an index.  I would love to have an option in the index
generator that says A and B are equivalent, so both A and B get a list of
the references to either.
I agree, but I can't see a way to do it in makeindex. Having said that ...

The single and most annoying thing anyone can do in an index is not 
provide an index.  Call me anal retentive, but I even want an index in a 
novel.

Robin

--
"A strategy is still being formulated."
Robin Turner
IDMYO
Bilkent Univeritesi
Ankara 06533
Turkey
www.bilkent.edu.tr/~robin

Re: Some info about lyx-qt 1.3.2 segfaults

[larry]

Yes, Fernando.  I experience the same failure, and posted the exact same screen
copy of gdb output to the lyx-devel list last Friday.  I can't get my
environment to survive the crash either, but ONLY under gdb, oddly.

No one has offered up an answer, and others suggest everything works the right
way.  Someone suggested that my build might be on top of incompatible libraries
and includes, but did not suggest how to investigate this.

More broadly, the failure occurs whenever trying to access a submenu using
keyboard shortcuts, under qt.

I'm using Redhat 9, kde/qt 3.1.2.  Failure under my own builds and circulating
rh9 rpms for lyx 1.3.2.

On Tue, Jul 01, 2003 at 11:52:16AM -0600, Fernando Perez wrote:
> Hi all,
> 
> I'm not subscribed to lyx-dev and I just have already too many email lists. 
> But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
> figured I'd add a bit of info in case it helps the developers.
> 
> Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org 
> supplied rpms.
> 
> Crash mode: start new document, press Alt-I-S (insert special character).  
> The 'Special' menu entry does NOT get highlighted, as it should.  Now, 
> press right arrow.  Lyx crashes.
> 
> I tried it under gdb, and when lyx dies, everything seems to lock up, 
> including the window manager.  But there's a way to recover: type 
> Ctrl-Alt-F1, log into a text terminal, and kill the gdb process by hand.  
> Then type Alt-F7 to go back to X.  The system is now unfrozen.
> 
> The following is a screen copy of the gdb output:
> 
> [~]> gdb lyx
> GNU gdb Red Hat Linux (5.2.1-4)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...(no debugging symbols 
> found)...
> (gdb) run
> Starting program: /usr/bin/lyx
> [New Thread 16384 (LWP 17855)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 17855)]
> 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
> /usr/lib/qt-3.1/lib/libqt-mt.so.3
> (gdb) Killed
> 
> lyx: SIGHUP signal caught
> Bye.
> [~]> Mutex destroy failure: Device or resource busy
> 
> 
> 
> This crash is 100% reproducible.
> 
> I hope this is of some use.
> 
> Best,
> 
> f.

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

[EMAIL PROTECTED] wrote:

> way.  Someone suggested that my build might be on top of incompatible
> libraries and includes, but did not suggest how to investigate this.

It seems that we have to discard this, since you (and others) get the same
with the precompiled version/with standard systems. 

> More broadly, the failure occurs whenever trying to access a submenu using
> keyboard shortcuts, under qt.
> 
> I'm using Redhat 9, kde/qt 3.1.2.  Failure under my own builds and
> circulating rh9 rpms for lyx 1.3.2.

I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.

Regards, Alfredo

Re: Some info about lyx-qt 1.3.2 segfaults

[Alfredo Braunstein]

Fernando Perez wrote:

> Anyway, enabling core files doesn't seem to help much, as the lyx.org rpms
> have no debugging info in them.  Sorry, but I don't have time right now to

Ah yes, forgot about that. 

Thanks anyway, Alfredo

backtrace on qt menu fails

[larry]

- Forwarded message from [EMAIL PROTECTED] -

From: [EMAIL PROTECTED]
Date: Tue, 1 Jul 2003 13:26:09 -0700
To: Alfredo Braunstein <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Really, nothing further on qt menu fails?

On Tue, Jul 01, 2003 at 08:25:26PM +0200, Alfredo Braunstein wrote:
> You may need to issue 
> ulimit -c unlimited
> to enable core dumps. 
> 
> Then do
> gdb core.PID lyx
> and then please post the output of 'bt' to the list.

Alfredo: 

Thanks for the brief tutorial.

Here is the bt:

(gdb) bt
#0  0xe002 in ?? ()
#1  0x42028b93 in abort () from /lib/tls/libc.so.6
#2  0x082bb7a3 in lyx::abort() ()
#3  0x080d5c11 in error_handler ()
#4  
#5  0x4031eef6 in QPopupMenu::keyPressEvent(QKeyEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#6  0x40288532 in QWidget::event(QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#7  0x402141d3 in QApplication::internalNotify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#8  0x40213e43 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3#9  0x401cccf3 in 
QETWidget::translateKeyEvent(_XEvent const*, bool) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#10 0x401c9738 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#11 0x401da8c4 in QEventLoop::processEvents(unsigned) ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#12 0x40223ef5 in QEventLoop::enterLoop() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#13 0x40223dc7 in QEventLoop::exec() () from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#14 0x40214386 in QApplication::exec() ()
   from /usr/lib/qt-3.1/lib/libqt-mt.so.3
#15 0x0821a0ab in lyx_gui::start(std::string const&, std::vector const&) ()
#16 0x080d5a48 in LyX::LyX(int&, char**) ()
#17 0x081060a5 in main ()
#18 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) ~

Again, this occurs with any use of keyboard shortcuts to access a submenu item,
like Edit-> Special Character   -> HFill the commands
  OK -> Item not highlighted-> CRASH the result

- End forwarded message -

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[John Levon]

On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:

> > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > types for `typedef struct OpaqueControlRef * ControlRef'
> > ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
> > `class ControlRef'
> 
> As far as I understand it, this is a naming clash. Qt has a 
> typedef struct OpaqueControlRef *ControlRef;

Has anyone reported this stupid bug to Troll Tech yet ?

regards
john

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Ronald Florence]

John Levon <[EMAIL PROTECTED]> writes:

> On Tue, Jun 24, 2003 at 07:48:01PM +0200, Juergen Spitzmueller wrote:
> 
> > > /usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: conflicting
> > > types for `typedef struct OpaqueControlRef * ControlRef'
> > > ../../../src/frontends/controllers/ControlRef.h:43: previous declaration as
> > > `class ControlRef'
> > 
> > As far as I understand it, this is a naming clash. Qt has a 
> > typedef struct OpaqueControlRef *ControlRef;
> 
> Has anyone reported this stupid bug to Troll Tech yet ?

The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
-- 

Ronald Florence www.18james.com

Re: Some info about lyx-qt 1.3.2 segfaults

[Matej Cepl]

On 2003-07-01, 20:42 GMT, Alfredo Braunstein wrote:
>> way.  Someone suggested that my build might be on top of incompatible
>> libraries and includes, but did not suggest how to investigate this.
> 
> It seems that we have to discard this, since you (and others) get the same
> with the precompiled version/with standard systems. 

Just to note, that my system is not standard (using additional KDE from
debian.kde.org).

Matej

-- 
Matej Cepl,
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
138 Highland Ave. #10, Somerville, Ma 02143, (617) 623-1488

Re: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

/usr/local/src/qt-mac-free-3.1.2/include/qwindowdefs.h:104: 
conflicting
types for `typedef struct OpaqueControlRef * ControlRef'
../../../src/frontends/controllers/ControlRef.h:43: previous 
declaration as
`class ControlRef'
As far as I understand it, this is a naming clash. Qt has a
typedef struct OpaqueControlRef *ControlRef;
Has anyone reported this stupid bug to Troll Tech yet ?
The Trolltech GPL-licensed QT/MacOSX libraries are not supported.  I
got Lyx-1.3.2 to compile with the libraries by changing all the
clashing ControlRef references in the LyX code to ControlLyXRef.  The
patch, which also includes patches for the configuration files and a
few other problems in building the Aqua native LyX, is at
http://www.18james.com/code/lyx-qt.patch .
I do not agree upon the statement that Trolltech is not interested in 
supporting
and  bug reports on QT/Aqua ! In fact, I think the opposite is the 
case: they want
open source programmers to report their bugs so that they can finally
solve most of them - thats why they released QT/Aqua under GPL in the 
first
place!

I suggest we send them every bug we find! And: whenever I asked them for
help, they responded so far!
Jan

Re: Some info about lyx-qt 1.3.2 segfaults

[Fernando Perez]

Alfredo Braunstein wrote:

I don't know if I've mentioned it, but I have Redhat 9, with the provided qt
3.1.1-6 and I cannot reproduce it at all.
More specifically (in case it helps you guys), I'm using RedHat 8.0, but I 
updated my qt/kde from freshrpms.org to:

kdelibs-3.1.2-0.fdr.3.rh80
qt-3.1.2-7.fdr.0.rh80
My Lyx is from lyx.org:

lyx-1.3.2-1_qt

Again, sorry I can't do deeper debugging here.

Best,

f.

Re: Some info about lyx-qt 1.3.2

[John Sheahan]

Hi Fernando

my computer is currently rh8.0 [1] with all current redhat updates.
Using a locally compiled lyx qt binary , does NOT crash following your
procedure.
Note my qt libs are older than yours.

 [EMAIL PROTECTED] john]$ ldd `which lyx`
libqt-mt.so.3 => /usr/lib/qt-3.0.5/lib/libqt-mt.so.3
(0x40028000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40657000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4066)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40677000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40755000)
libm.so.6 => /lib/i686/libm.so.6 (0x40807000)
libc.so.6 => /lib/i686/libc.so.6 (0x4200)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4082a000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40832000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x40882000)
libmng.so.1 => /usr/lib/libmng.so.1 (0x4089c000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x408e)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x408fe000)
libz.so.1 => /usr/lib/libz.so.1 (0x40922000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x4093)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x409a3000)
libdl.so.2 => /lib/libdl.so.2 (0x409b9000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x409bc000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x409ca000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x409d)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x409e2000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
libssl.so.2 => /lib/libssl.so.2 (0x40a07000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40a37000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40b0b000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x40b5e000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40ba7000)


[1] xinerama on rh9's XFree86 4.3 is too unstable with a matrox G450 to
use. If you have not used xinerama on 2 monitors, I suggest you don't, 
as its impossible to go back.  Disabling x font render helps some. 

john



On Wed, 2003-07-02 at 03:52, Fernando Perez wrote:
> Hi all,
> 
> I'm not subscribed to lyx-dev and I just have already too many email lists. 
> But I saw a discussion about lyx-qt 1.3.2 segfaulting under redhat, and I 
> figured I'd add a bit of info in case it helps the developers.
> 
> Platform: RedHat 8.0, KDE 3.1, Qt 3.1.  Lyx 1.3.2, using the Lyx.org supplied 
> rpms.
> 
> Crash mode: start new document, press Alt-I-S (insert special character).  The 
> 'Special' menu entry does NOT get highlighted, as it should.  Now, press right 
> arrow.  Lyx crashes.
> 
> I tried it under gdb, and when lyx dies, everything seems to lock up, 
> including the window manager.  But there's a way to recover: type Ctrl-Alt-F1, 
> log into a text terminal, and kill the gdb process by hand.  Then type Alt-F7 
> to go back to X.  The system is now unfrozen.
> 
> The following is a screen copy of the gdb output:
> 
> [~]> gdb lyx
> GNU gdb Red Hat Linux (5.2.1-4)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...
> (gdb) run
> Starting program: /usr/bin/lyx
> [New Thread 16384 (LWP 17855)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 17855)]
> 0x40317212 in QPopupMenu::keyPressEvent(QKeyEvent*) () from 
> /usr/lib/qt-3.1/lib/libqt-mt.so.3
> (gdb) Killed
> 
> lyx: SIGHUP signal caught
> Bye.
> [~]> Mutex destroy failure: Device or resource busy
> 
> 
> 
> This crash is 100% reproducible.
> 
> I hope this is of some use.
> 
> Best,
> 
> f.

Fwd: [Issue N25717] Fwd: compilation problem with Trolltech MacOSX/GPL QT libraries

[Jan Peters]

I mailed Trolltech about the discussion, and there reply is:

I agree, you can safely remove it from qwindowdefs.h. Originally it was
thought to be necessary for future plans, but not.
However, using ControlRef might be a bad idea in any event as it is a
type in Carbon so including some headers could indeed pull it in
otherwise.
Regards
//Sam