Re: shared library run problem

2012-02-26 Thread Stephan Witt
Am 26.02.2012 um 00:19 schrieb Sajjad:

 Hi 
 
 i ran the suggested diagnostics and found the following result:
 
 
 sajjad@sajjad:~$ ldd /usr/local/bin/lyx
 linux-vdso.so.1 = (0x7fff853ff000)
 libenchant.so.1 = /usr/lib/libenchant.so.1 (0x7fd3d926b000)
 libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
 libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
 libz.so.1 = /usr/lib/libz.so.1 (0x7fd3d8b8a000)
 libQtGui.so.4 = not found
 libQtCore.so.4 = not found
 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
 libm.so.6 = /lib/libm.so.6 (0x7fd3d85f8000)
 libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fd3d83e)
 libc.so.6 = /lib/libc.so.6 (0x7fd3d806e000)
 libpthread.so.0 = /lib/libpthread.so.0 (0x7fd3d7e52000)
 libdl.so.2 = /lib/libdl.so.2 (0x7fd3d7c4e000)
 libpcre.so.3 = /lib/libpcre.so.3 (0x7fd3d7a25000)
 /lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)
 
 
 
 
 
 
 It shows that the qt library is not found. As you have seen in the previous 
 post, the output of the ./configure shows that the qt library is found. While 
 configuring  i did mention the full qt path.

Yes. That's exactly the situation: While configuring you told the compiler 
where to find your own Qt-Libraries. 
Your problem is now: you don't tell the runtime-linker where you've put the 
Qt-Libraries on your machine when running lyx.
You have to decide how to solve that. You may
1. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your system library 
path
   You have to become root and add the mentioned path to the file 
/etc/ld.so.conf and run the command ldconfig
2. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your user library path
   You have to add the mentioned directory to the value of LD_LIBRARY_PATH on 
user login.
3. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your lyx call.
   You have to create a shell script and set LD_LIBRARY_PATH there and run lyx 
from this script.
--- example ---
#!/bin/sh
LD_LIBRARY_PATH=/usr/local/Trolltech/Qt-4.8.0/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
exec /path/to/lyx $@
--- end of example ---

Check the man pages for details or google for the explanations for shared 
library runtime link operation.

Stephan

 On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck rgh...@comcast.net wrote:
 On 02/25/2012 08:48 AM, Sajjad wrote:
 Hello
 
 I am using an old machine and repository support went out. I recently 
 updated the qt version to 4.8.0 from source.
 
 While configuring the lyx source i am providing wiith the qt path and it did 
 not complain at all:
 
 This is just a matter of finding the headers. It doesn't have anything to do 
 with which libraries the system is trying to load when LyX requests them. 
 Try, as Stephan suggested:
  ldd /path/to/lyx
 
 Richard
 
 
 //
 
 sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure 
 --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
 configuring LyX version 2.0.0
 checking for build type... release
 checking for version suffix... 
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking target system type... x86_64-unknown-linux-gnu
 checking what packaging should be used... posix
 checking whether to enable maintainer-specific portions of Makefiles... no
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for a Python interpreter with version = 2.3.4... python
 checking for python... /usr/bin/python
 checking for python version... 2.5
 checking for python platform... linux2
 checking for python script directory... ${prefix}/lib/python2.5/site-packages
 checking for python extension module directory... 
 ${exec_prefix}/lib/python2.5/site-packages
 checking for style of include used by make... GNU
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables... 
 checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... gcc3
 checking how to run the C preprocessor... gcc -E
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
 checking for ANSI C header files... yes
 checking for 

Re: shared library run problem

2012-02-26 Thread Sajjad
Wow!!

That was an hell of an example. Thanks a lot.

The path was already set by me inside the ld.so.conf. I had to add another
level(lib/) and now it is up and running


Thanks again folks

Sajjad

On Sun, Feb 26, 2012 at 1:31 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 26.02.2012 um 00:19 schrieb Sajjad:

  Hi
 
  i ran the suggested diagnostics and found the following result:
 
 
 
  sajjad@sajjad:~$ ldd /usr/local/bin/lyx
  linux-vdso.so.1 = (0x7fff853ff000)
  libenchant.so.1 = /usr/lib/libenchant.so.1 (0x7fd3d926b000)
  libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
  libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
  libz.so.1 = /usr/lib/libz.so.1 (0x7fd3d8b8a000)
  libQtGui.so.4 = not found
  libQtCore.so.4 = not found
  libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
  libm.so.6 = /lib/libm.so.6 (0x7fd3d85f8000)
  libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fd3d83e)
  libc.so.6 = /lib/libc.so.6 (0x7fd3d806e000)
  libpthread.so.0 = /lib/libpthread.so.0 (0x7fd3d7e52000)
  libdl.so.2 = /lib/libdl.so.2 (0x7fd3d7c4e000)
  libpcre.so.3 = /lib/libpcre.so.3 (0x7fd3d7a25000)
  /lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)
 
 
 
 
 
 
 
  It shows that the qt library is not found. As you have seen in the
 previous post, the output of the ./configure shows that the qt library is
 found. While configuring  i did mention the full qt path.

 Yes. That's exactly the situation: While configuring you told the compiler
 where to find your own Qt-Libraries.
 Your problem is now: you don't tell the runtime-linker where you've put
 the Qt-Libraries on your machine when running lyx.
 You have to decide how to solve that. You may
 1. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your system
 library path
   You have to become root and add the mentioned path to the file
 /etc/ld.so.conf and run the command ldconfig
 2. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your user
 library path
   You have to add the mentioned directory to the value of LD_LIBRARY_PATH
 on user login.
 3. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your lyx call.
   You have to create a shell script and set LD_LIBRARY_PATH there and run
 lyx from this script.
 --- example ---
 #!/bin/sh
 LD_LIBRARY_PATH=/usr/local/Trolltech/Qt-4.8.0/lib:$LD_LIBRARY_PATH
 export LD_LIBRARY_PATH
 exec /path/to/lyx $@
 --- end of example ---

 Check the man pages for details or google for the explanations for shared
 library runtime link operation.

 Stephan

  On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck rgh...@comcast.net
 wrote:
  On 02/25/2012 08:48 AM, Sajjad wrote:
  Hello
 
  I am using an old machine and repository support went out. I recently
 updated the qt version to 4.8.0 from source.
 
  While configuring the lyx source i am providing wiith the qt path and
 it did not complain at all:
 
  This is just a matter of finding the headers. It doesn't have anything
 to do with which libraries the system is trying to load when LyX requests
 them. Try, as Stephan suggested:
   ldd /path/to/lyx
 
  Richard
 
 
 
 //
 
  sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
 --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
  configuring LyX version 2.0.0
  checking for build type... release
  checking for version suffix...
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... x86_64-unknown-linux-gnu
  checking target system type... x86_64-unknown-linux-gnu
  checking what packaging should be used... posix
  checking whether to enable maintainer-specific portions of Makefiles...
 no
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... gawk
  checking whether make sets $(MAKE)... yes
  checking for a Python interpreter with version = 2.3.4... python
  checking for python... /usr/bin/python
  checking for python version... 2.5
  checking for python platform... linux2
  checking for python script directory...
 ${prefix}/lib/python2.5/site-packages
  checking for python extension module directory...
 ${exec_prefix}/lib/python2.5/site-packages
  checking for style of include used by make... GNU
  checking for gcc... gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.out
  checking for suffix of executables...
  checking whether we are cross compiling... no
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  

Re: shared library run problem

2012-02-26 Thread Stephan Witt
Am 26.02.2012 um 00:19 schrieb Sajjad:

 Hi 
 
 i ran the suggested diagnostics and found the following result:
 
 
 sajjad@sajjad:~$ ldd /usr/local/bin/lyx
 linux-vdso.so.1 = (0x7fff853ff000)
 libenchant.so.1 = /usr/lib/libenchant.so.1 (0x7fd3d926b000)
 libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
 libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
 libz.so.1 = /usr/lib/libz.so.1 (0x7fd3d8b8a000)
 libQtGui.so.4 = not found
 libQtCore.so.4 = not found
 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
 libm.so.6 = /lib/libm.so.6 (0x7fd3d85f8000)
 libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fd3d83e)
 libc.so.6 = /lib/libc.so.6 (0x7fd3d806e000)
 libpthread.so.0 = /lib/libpthread.so.0 (0x7fd3d7e52000)
 libdl.so.2 = /lib/libdl.so.2 (0x7fd3d7c4e000)
 libpcre.so.3 = /lib/libpcre.so.3 (0x7fd3d7a25000)
 /lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)
 
 
 
 
 
 
 It shows that the qt library is not found. As you have seen in the previous 
 post, the output of the ./configure shows that the qt library is found. While 
 configuring  i did mention the full qt path.

Yes. That's exactly the situation: While configuring you told the compiler 
where to find your own Qt-Libraries. 
Your problem is now: you don't tell the runtime-linker where you've put the 
Qt-Libraries on your machine when running lyx.
You have to decide how to solve that. You may
1. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your system library 
path
   You have to become root and add the mentioned path to the file 
/etc/ld.so.conf and run the command ldconfig
2. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your user library path
   You have to add the mentioned directory to the value of LD_LIBRARY_PATH on 
user login.
3. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your lyx call.
   You have to create a shell script and set LD_LIBRARY_PATH there and run lyx 
from this script.
--- example ---
#!/bin/sh
LD_LIBRARY_PATH=/usr/local/Trolltech/Qt-4.8.0/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
exec /path/to/lyx $@
--- end of example ---

Check the man pages for details or google for the explanations for shared 
library runtime link operation.

Stephan

 On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck rgh...@comcast.net wrote:
 On 02/25/2012 08:48 AM, Sajjad wrote:
 Hello
 
 I am using an old machine and repository support went out. I recently 
 updated the qt version to 4.8.0 from source.
 
 While configuring the lyx source i am providing wiith the qt path and it did 
 not complain at all:
 
 This is just a matter of finding the headers. It doesn't have anything to do 
 with which libraries the system is trying to load when LyX requests them. 
 Try, as Stephan suggested:
  ldd /path/to/lyx
 
 Richard
 
 
 //
 
 sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure 
 --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
 configuring LyX version 2.0.0
 checking for build type... release
 checking for version suffix... 
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking target system type... x86_64-unknown-linux-gnu
 checking what packaging should be used... posix
 checking whether to enable maintainer-specific portions of Makefiles... no
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for a Python interpreter with version = 2.3.4... python
 checking for python... /usr/bin/python
 checking for python version... 2.5
 checking for python platform... linux2
 checking for python script directory... ${prefix}/lib/python2.5/site-packages
 checking for python extension module directory... 
 ${exec_prefix}/lib/python2.5/site-packages
 checking for style of include used by make... GNU
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables... 
 checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... gcc3
 checking how to run the C preprocessor... gcc -E
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
 checking for ANSI C header files... yes
 checking for 

Re: shared library run problem

2012-02-26 Thread Sajjad
Wow!!

That was an hell of an example. Thanks a lot.

The path was already set by me inside the ld.so.conf. I had to add another
level(lib/) and now it is up and running


Thanks again folks

Sajjad

On Sun, Feb 26, 2012 at 1:31 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 26.02.2012 um 00:19 schrieb Sajjad:

  Hi
 
  i ran the suggested diagnostics and found the following result:
 
 
 
  sajjad@sajjad:~$ ldd /usr/local/bin/lyx
  linux-vdso.so.1 = (0x7fff853ff000)
  libenchant.so.1 = /usr/lib/libenchant.so.1 (0x7fd3d926b000)
  libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
  libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
  libz.so.1 = /usr/lib/libz.so.1 (0x7fd3d8b8a000)
  libQtGui.so.4 = not found
  libQtCore.so.4 = not found
  libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
  libm.so.6 = /lib/libm.so.6 (0x7fd3d85f8000)
  libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fd3d83e)
  libc.so.6 = /lib/libc.so.6 (0x7fd3d806e000)
  libpthread.so.0 = /lib/libpthread.so.0 (0x7fd3d7e52000)
  libdl.so.2 = /lib/libdl.so.2 (0x7fd3d7c4e000)
  libpcre.so.3 = /lib/libpcre.so.3 (0x7fd3d7a25000)
  /lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)
 
 
 
 
 
 
 
  It shows that the qt library is not found. As you have seen in the
 previous post, the output of the ./configure shows that the qt library is
 found. While configuring  i did mention the full qt path.

 Yes. That's exactly the situation: While configuring you told the compiler
 where to find your own Qt-Libraries.
 Your problem is now: you don't tell the runtime-linker where you've put
 the Qt-Libraries on your machine when running lyx.
 You have to decide how to solve that. You may
 1. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your system
 library path
   You have to become root and add the mentioned path to the file
 /etc/ld.so.conf and run the command ldconfig
 2. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your user
 library path
   You have to add the mentioned directory to the value of LD_LIBRARY_PATH
 on user login.
 3. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your lyx call.
   You have to create a shell script and set LD_LIBRARY_PATH there and run
 lyx from this script.
 --- example ---
 #!/bin/sh
 LD_LIBRARY_PATH=/usr/local/Trolltech/Qt-4.8.0/lib:$LD_LIBRARY_PATH
 export LD_LIBRARY_PATH
 exec /path/to/lyx $@
 --- end of example ---

 Check the man pages for details or google for the explanations for shared
 library runtime link operation.

 Stephan

  On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck rgh...@comcast.net
 wrote:
  On 02/25/2012 08:48 AM, Sajjad wrote:
  Hello
 
  I am using an old machine and repository support went out. I recently
 updated the qt version to 4.8.0 from source.
 
  While configuring the lyx source i am providing wiith the qt path and
 it did not complain at all:
 
  This is just a matter of finding the headers. It doesn't have anything
 to do with which libraries the system is trying to load when LyX requests
 them. Try, as Stephan suggested:
   ldd /path/to/lyx
 
  Richard
 
 
 
 //
 
  sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
 --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
  configuring LyX version 2.0.0
  checking for build type... release
  checking for version suffix...
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... x86_64-unknown-linux-gnu
  checking target system type... x86_64-unknown-linux-gnu
  checking what packaging should be used... posix
  checking whether to enable maintainer-specific portions of Makefiles...
 no
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... gawk
  checking whether make sets $(MAKE)... yes
  checking for a Python interpreter with version = 2.3.4... python
  checking for python... /usr/bin/python
  checking for python version... 2.5
  checking for python platform... linux2
  checking for python script directory...
 ${prefix}/lib/python2.5/site-packages
  checking for python extension module directory...
 ${exec_prefix}/lib/python2.5/site-packages
  checking for style of include used by make... GNU
  checking for gcc... gcc
  checking whether the C compiler works... yes
  checking for C compiler default output file name... a.out
  checking for suffix of executables...
  checking whether we are cross compiling... no
  checking for suffix of object files... o
  checking whether we are using the GNU C compiler... yes
  

Re: shared library run problem

2012-02-26 Thread Stephan Witt
Am 26.02.2012 um 00:19 schrieb Sajjad:

> Hi 
> 
> i ran the suggested diagnostics and found the following result:
> 
> 
> sajjad@sajjad:~$ ldd /usr/local/bin/lyx
> linux-vdso.so.1 => (0x7fff853ff000)
> libenchant.so.1 => /usr/lib/libenchant.so.1 (0x7fd3d926b000)
> libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
> libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
> libz.so.1 => /usr/lib/libz.so.1 (0x7fd3d8b8a000)
> libQtGui.so.4 => not found
> libQtCore.so.4 => not found
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
> libm.so.6 => /lib/libm.so.6 (0x7fd3d85f8000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fd3d83e)
> libc.so.6 => /lib/libc.so.6 (0x7fd3d806e000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x7fd3d7e52000)
> libdl.so.2 => /lib/libdl.so.2 (0x7fd3d7c4e000)
> libpcre.so.3 => /lib/libpcre.so.3 (0x7fd3d7a25000)
> /lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)
> 
> 
> 
> 
> 
> 
> It shows that the qt library is not found. As you have seen in the previous 
> post, the output of the ./configure shows that the qt library is found. While 
> configuring  i did mention the full qt path.

Yes. That's exactly the situation: While configuring you told the compiler 
where to find your own Qt-Libraries. 
Your problem is now: you don't tell the runtime-linker where you've put the 
Qt-Libraries on your machine when running lyx.
You have to decide how to solve that. You may
1. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your system library 
path
   You have to become root and add the mentioned path to the file 
/etc/ld.so.conf and run the command ldconfig
2. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your user library path
   You have to add the mentioned directory to the value of LD_LIBRARY_PATH on 
user login.
3. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your lyx call.
   You have to create a shell script and set LD_LIBRARY_PATH there and run lyx 
from this script.
--- example ---
#!/bin/sh
LD_LIBRARY_PATH=/usr/local/Trolltech/Qt-4.8.0/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
exec /path/to/lyx "$@"
--- end of example ---

Check the man pages for details or google for the explanations for shared 
library runtime link operation.

Stephan

> On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck  wrote:
> On 02/25/2012 08:48 AM, Sajjad wrote:
>> Hello
>> 
>> I am using an old machine and repository support went out. I recently 
>> updated the qt version to 4.8.0 from source.
>> 
>> While configuring the lyx source i am providing wiith the qt path and it did 
>> not complain at all:
>> 
> This is just a matter of finding the headers. It doesn't have anything to do 
> with which libraries the system is trying to load when LyX requests them. 
> Try, as Stephan suggested:
> > ldd /path/to/lyx
> 
> Richard
> 
> 
>> //
>> 
>> sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure 
>> --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
>> configuring LyX version 2.0.0
>> checking for build type... release
>> checking for version suffix... 
>> checking build system type... x86_64-unknown-linux-gnu
>> checking host system type... x86_64-unknown-linux-gnu
>> checking target system type... x86_64-unknown-linux-gnu
>> checking what packaging should be used... posix
>> checking whether to enable maintainer-specific portions of Makefiles... no
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for a thread-safe mkdir -p... /bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking for a Python interpreter with version >= 2.3.4... python
>> checking for python... /usr/bin/python
>> checking for python version... 2.5
>> checking for python platform... linux2
>> checking for python script directory... ${prefix}/lib/python2.5/site-packages
>> checking for python extension module directory... 
>> ${exec_prefix}/lib/python2.5/site-packages
>> checking for style of include used by make... GNU
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables... 
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to accept ISO C89... none needed
>> checking dependency style of gcc... gcc3
>> checking how to run the C preprocessor... gcc -E
>> checking 

Re: shared library run problem

2012-02-26 Thread Sajjad
Wow!!

That was an hell of an example. Thanks a lot.

The path was already set by me inside the ld.so.conf. I had to add another
level(lib/) and now it is up and running


Thanks again folks

Sajjad

On Sun, Feb 26, 2012 at 1:31 PM, Stephan Witt  wrote:

> Am 26.02.2012 um 00:19 schrieb Sajjad:
>
> > Hi
> >
> > i ran the suggested diagnostics and found the following result:
> >
> >
> 
> > sajjad@sajjad:~$ ldd /usr/local/bin/lyx
> > linux-vdso.so.1 => (0x7fff853ff000)
> > libenchant.so.1 => /usr/lib/libenchant.so.1 (0x7fd3d926b000)
> > libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
> > libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
> > libz.so.1 => /usr/lib/libz.so.1 (0x7fd3d8b8a000)
> > libQtGui.so.4 => not found
> > libQtCore.so.4 => not found
> > libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
> > libm.so.6 => /lib/libm.so.6 (0x7fd3d85f8000)
> > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fd3d83e)
> > libc.so.6 => /lib/libc.so.6 (0x7fd3d806e000)
> > libpthread.so.0 => /lib/libpthread.so.0 (0x7fd3d7e52000)
> > libdl.so.2 => /lib/libdl.so.2 (0x7fd3d7c4e000)
> > libpcre.so.3 => /lib/libpcre.so.3 (0x7fd3d7a25000)
> > /lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)
> >
> >
> >
> >
> 
> >
> >
> > It shows that the qt library is not found. As you have seen in the
> previous post, the output of the ./configure shows that the qt library is
> found. While configuring  i did mention the full qt path.
>
> Yes. That's exactly the situation: While configuring you told the compiler
> where to find your own Qt-Libraries.
> Your problem is now: you don't tell the runtime-linker where you've put
> the Qt-Libraries on your machine when running lyx.
> You have to decide how to solve that. You may
> 1. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your system
> library path
>   You have to become root and add the mentioned path to the file
> /etc/ld.so.conf and run the command ldconfig
> 2. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your user
> library path
>   You have to add the mentioned directory to the value of LD_LIBRARY_PATH
> on user login.
> 3. add the directory /usr/local/Trolltech/Qt-4.8.0/lib to your lyx call.
>   You have to create a shell script and set LD_LIBRARY_PATH there and run
> lyx from this script.
> --- example ---
> #!/bin/sh
> LD_LIBRARY_PATH=/usr/local/Trolltech/Qt-4.8.0/lib:$LD_LIBRARY_PATH
> export LD_LIBRARY_PATH
> exec /path/to/lyx "$@"
> --- end of example ---
>
> Check the man pages for details or google for the explanations for shared
> library runtime link operation.
>
> Stephan
>
> > On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck 
> wrote:
> > On 02/25/2012 08:48 AM, Sajjad wrote:
> >> Hello
> >>
> >> I am using an old machine and repository support went out. I recently
> updated the qt version to 4.8.0 from source.
> >>
> >> While configuring the lyx source i am providing wiith the qt path and
> it did not complain at all:
> >>
> > This is just a matter of finding the headers. It doesn't have anything
> to do with which libraries the system is trying to load when LyX requests
> them. Try, as Stephan suggested:
> > > ldd /path/to/lyx
> >
> > Richard
> >
> >
> >>
> //
> >>
> >> sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
> --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
> >> configuring LyX version 2.0.0
> >> checking for build type... release
> >> checking for version suffix...
> >> checking build system type... x86_64-unknown-linux-gnu
> >> checking host system type... x86_64-unknown-linux-gnu
> >> checking target system type... x86_64-unknown-linux-gnu
> >> checking what packaging should be used... posix
> >> checking whether to enable maintainer-specific portions of Makefiles...
> no
> >> checking for a BSD-compatible install... /usr/bin/install -c
> >> checking whether build environment is sane... yes
> >> checking for a thread-safe mkdir -p... /bin/mkdir -p
> >> checking for gawk... gawk
> >> checking whether make sets $(MAKE)... yes
> >> checking for a Python interpreter with version >= 2.3.4... python
> >> checking for python... /usr/bin/python
> >> checking for python version... 2.5
> >> checking for python platform... linux2
> >> checking for python script directory...
> ${prefix}/lib/python2.5/site-packages
> >> checking for python extension module directory...
> ${exec_prefix}/lib/python2.5/site-packages
> >> checking for style of include used by make... GNU
> >> checking for gcc... gcc
> >> checking whether the C compiler works... yes
> >> checking for C 

Re: shared library run problem

2012-02-25 Thread Stephan Witt
Am 25.02.2012 um 05:57 schrieb Sajjad:

 I compiled both qt and lyx from source. The installation instructions for qt 
 did not mention anything about this issue and it is working fine.
 
 Is there any way to send the parameter while configuring lyx so that the 
 compilation is done against the 32 -bit instead ?

Why did you compile Qt form source? Didn't you have it already installed?
I think it's better to use the system Qt and install the missing developer 
package if needed. 
You have to be sure to provide the correct version of Qt at runtime if you want 
to use your own package.
To verify that you may use ldd /path/to/lyx to check what Qt-libraries are 
linked at run time. 
Perhaps you have to adjust your LD_LIBRARY_PATH variable accordingly.

Stephan

 
 I am using the 64-bit ubuntu. 
 
 
 
 On Fri, Feb 24, 2012 at 6:34 PM, Richard Heck rgh...@comcast.net wrote:
 On 02/24/2012 09:51 AM, Sajjad wrote:
  hello forum,
 
  I just managed to compile LyX from source and it compiled fine. The qt
  path is mentioned while configuring and configuring.
 
  Now when i try to run lyx or lyxclient i get the following error:
 
  /
  sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
  libQtGui.so.4: wrong ELF class: ELFCLASS32
  
 
 It looks like LyX has been compiled as a 64 bit app, but what's being
 found are 32 bit libraries. I'm afraid I don't know why this would be.
 But maybe that's a clue?
 
 Richard
 
 



Auto response - re:Re: shared library run problem [pfCase:2108434, pfTicket:7384782]

2012-02-25 Thread support
pfTicket: 7384782

Thank you for e-mailing the Casino Support Desk.

We have assigned your query one of our Support Consultants and you should 
receive a response soon.

While we do our best to ensure that all e-mails are responded to as quickly as 
possible, it can – on rare occasions – take a bit of time for us to get a 
response back to you

Should you urgently require a response, we would suggest that you please 
contact us via our Toll Free Numbers, listed below

Kind Regards

Casino Support

Support Hours
24 Hours a Day, 7 Days a Week 

Contact Numbers

Argentina: 08004440973
Australia: 1-800-658460
Austria: 085080
Belgium: 080049216
Canada: 18667452416
Chile: 12300207689
Cyprus: 80077315
Denmark: 80887134
Finland: 800919692
Germany: 0803370
Greece: 00 800-127-304
Hong Kong: 800-903483
Italy: 800986542
Malaysia: 1800812500
Mexico: 18669724381
Netherlands: 08000204703
New Zealand: 0800449767
Norway: 80019453
Portugal: 800-814053
Singapore: 800-1204340
Spain: 800 3000 87
Sweden: 0200-899-162
Switzerland: 081722
Thailand: 1-801-20665859
UK: 0-808-2386055


Re: shared library run problem

2012-02-25 Thread Sajjad
Hello


I am using an old machine and repository support went out. I recently
updated the qt version to 4.8.0 from source.

While configuring the lyx source i am providing wiith the qt path and it
did not complain at all:

//

sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
--with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
configuring LyX version 2.0.0
checking for build type... release
checking for version suffix...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for a Python interpreter with version = 2.3.4... python
checking for python... /usr/bin/python
checking for python version... 2.5
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.5/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.5/site-packages
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking what frontend should be used for the GUI... qt4
checking for a good enough C++ compiler... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration... install-shextern size_t iconv (iconv_t
cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t
*outbytesleft);
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for gzopen in -lz... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... yes
checking for QT4_FRONTEND... yes
checking for moc-qt4... no
checking for moc... /usr/local/Trolltech/Qt-4.8.0///bin/moc
checking for uic-qt4... no
checking for uic... /usr/local/Trolltech/Qt-4.8.0///bin/uic
checking for rcc-qt4... no
checking for rcc... /usr/local/Trolltech/Qt-4.8.0///bin/rcc
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking whether we are using the GNU C Library 2 or newer... yes
checking for ranlib... ranlib
checking for simple visibility declarations... yes
checking for inline... inline
checking for size_t... yes
checking for stdint.h... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking whether integer division by zero raises SIGFPE... yes
checking for inttypes.h... yes
checking for unsigned 

Re: shared library run problem

2012-02-25 Thread Richard Heck

On 02/25/2012 08:48 AM, Sajjad wrote:

Hello


I am using an old machine and repository support went out. I recently 
updated the qt version to 4.8.0 from source.


While configuring the lyx source i am providing wiith the qt path and 
it did not complain at all:


This is just a matter of finding the headers. It doesn't have anything 
to do with which libraries the system is trying to load when LyX 
requests them. Try, as Stephan suggested:

 ldd /path/to/lyx

Richard


//

sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure 
--with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'

configuring LyX version 2.0.0
checking for build type... release
checking for version suffix...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for a Python interpreter with version = 2.3.4... python
checking for python... /usr/bin/python
checking for python version... 2.5
checking for python platform... linux2
checking for python script directory... 
${prefix}/lib/python2.5/site-packages
checking for python extension module directory... 
${exec_prefix}/lib/python2.5/site-packages

checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking what frontend should be used for the GUI... qt4
checking for a good enough C++ compiler... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration... install-shextern size_t iconv 
(iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, 
size_t *outbytesleft);

checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for gzopen in -lz... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... yes
checking for QT4_FRONTEND... yes
checking for moc-qt4... no
checking for moc... /usr/local/Trolltech/Qt-4.8.0///bin/moc
checking for uic-qt4... no
checking for uic... /usr/local/Trolltech/Qt-4.8.0///bin/uic
checking for rcc-qt4... no
checking for rcc... /usr/local/Trolltech/Qt-4.8.0///bin/rcc
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking whether we are using the GNU C Library 2 or newer... yes
checking for ranlib... ranlib
checking for simple visibility declarations... yes
checking for inline... inline
checking for size_t... yes
checking for stdint.h... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for stdlib.h... 

Re: shared library run problem

2012-02-25 Thread Sajjad
Hi

i ran the suggested diagnostics and found the following result:


sajjad@sajjad:~$ ldd /usr/local/bin/lyx
linux-vdso.so.1 = (0x7fff853ff000)
libenchant.so.1 = /usr/lib/libenchant.so.1 (0x7fd3d926b000)
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
libz.so.1 = /usr/lib/libz.so.1 (0x7fd3d8b8a000)
libQtGui.so.4 = not found
libQtCore.so.4 = not found
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
libm.so.6 = /lib/libm.so.6 (0x7fd3d85f8000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fd3d83e)
libc.so.6 = /lib/libc.so.6 (0x7fd3d806e000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7fd3d7e52000)
libdl.so.2 = /lib/libdl.so.2 (0x7fd3d7c4e000)
libpcre.so.3 = /lib/libpcre.so.3 (0x7fd3d7a25000)
/lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)






It shows that the qt library is not found. As you have seen in the previous
post, the output of the ./configure shows that the qt library is found.
While configuring  i did mention the full qt path.

What should i check now ?


Regards
Sajjad


On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck rgh...@comcast.net wrote:

  On 02/25/2012 08:48 AM, Sajjad wrote:

 Hello


  I am using an old machine and repository support went out. I recently
 updated the qt version to 4.8.0 from source.

  While configuring the lyx source i am providing wiith the qt path and it
 did not complain at all:

  This is just a matter of finding the headers. It doesn't have anything
 to do with which libraries the system is trying to load when LyX requests
 them. Try, as Stephan suggested:
  ldd /path/to/lyx

 Richard



 //

  sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
 --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
 configuring LyX version 2.0.0
 checking for build type... release
 checking for version suffix...
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking target system type... x86_64-unknown-linux-gnu
 checking what packaging should be used... posix
 checking whether to enable maintainer-specific portions of Makefiles... no
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for a Python interpreter with version = 2.3.4... python
 checking for python... /usr/bin/python
 checking for python version... 2.5
 checking for python platform... linux2
 checking for python script directory...
 ${prefix}/lib/python2.5/site-packages
 checking for python extension module directory...
 ${exec_prefix}/lib/python2.5/site-packages
 checking for style of include used by make... GNU
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables...
 checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... gcc3
 checking how to run the C preprocessor... gcc -E
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking whether byte ordering is bigendian... no
 checking what frontend should be used for the GUI... qt4
 checking for a good enough C++ compiler... g++
 checking whether we are using the GNU C++ compiler... yes
 checking whether g++ accepts -g... yes
 checking dependency style of g++... gcc3
 checking how to run the C++ preprocessor... g++ -E
 checking for gcc... gcc
 checking whether we are using the GNU Objective C compiler... no
 checking whether gcc accepts -g... no
 checking dependency style of gcc... gcc3
 checking dependency style of gcc... (cached) gcc3
 checking for extra library directory... NONE
 checking for extra include directory... NONE
 checking for extra lib+include directory... NONE
 checking for main in -lshlwapi... no
 checking for main in -lpsapi... no
 checking for main in -lgdi32... no
 checking whether to use included boost library... 

Re: shared library run problem

2012-02-25 Thread Stephan Witt
Am 25.02.2012 um 05:57 schrieb Sajjad:

 I compiled both qt and lyx from source. The installation instructions for qt 
 did not mention anything about this issue and it is working fine.
 
 Is there any way to send the parameter while configuring lyx so that the 
 compilation is done against the 32 -bit instead ?

Why did you compile Qt form source? Didn't you have it already installed?
I think it's better to use the system Qt and install the missing developer 
package if needed. 
You have to be sure to provide the correct version of Qt at runtime if you want 
to use your own package.
To verify that you may use ldd /path/to/lyx to check what Qt-libraries are 
linked at run time. 
Perhaps you have to adjust your LD_LIBRARY_PATH variable accordingly.

Stephan

 
 I am using the 64-bit ubuntu. 
 
 
 
 On Fri, Feb 24, 2012 at 6:34 PM, Richard Heck rgh...@comcast.net wrote:
 On 02/24/2012 09:51 AM, Sajjad wrote:
  hello forum,
 
  I just managed to compile LyX from source and it compiled fine. The qt
  path is mentioned while configuring and configuring.
 
  Now when i try to run lyx or lyxclient i get the following error:
 
  /
  sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
  libQtGui.so.4: wrong ELF class: ELFCLASS32
  
 
 It looks like LyX has been compiled as a 64 bit app, but what's being
 found are 32 bit libraries. I'm afraid I don't know why this would be.
 But maybe that's a clue?
 
 Richard
 
 



Auto response - re:Re: shared library run problem [pfCase:2108434, pfTicket:7384782]

2012-02-25 Thread support
pfTicket: 7384782

Thank you for e-mailing the Casino Support Desk.

We have assigned your query one of our Support Consultants and you should 
receive a response soon.

While we do our best to ensure that all e-mails are responded to as quickly as 
possible, it can – on rare occasions – take a bit of time for us to get a 
response back to you

Should you urgently require a response, we would suggest that you please 
contact us via our Toll Free Numbers, listed below

Kind Regards

Casino Support

Support Hours
24 Hours a Day, 7 Days a Week 

Contact Numbers

Argentina: 08004440973
Australia: 1-800-658460
Austria: 085080
Belgium: 080049216
Canada: 18667452416
Chile: 12300207689
Cyprus: 80077315
Denmark: 80887134
Finland: 800919692
Germany: 0803370
Greece: 00 800-127-304
Hong Kong: 800-903483
Italy: 800986542
Malaysia: 1800812500
Mexico: 18669724381
Netherlands: 08000204703
New Zealand: 0800449767
Norway: 80019453
Portugal: 800-814053
Singapore: 800-1204340
Spain: 800 3000 87
Sweden: 0200-899-162
Switzerland: 081722
Thailand: 1-801-20665859
UK: 0-808-2386055


Re: shared library run problem

2012-02-25 Thread Sajjad
Hello


I am using an old machine and repository support went out. I recently
updated the qt version to 4.8.0 from source.

While configuring the lyx source i am providing wiith the qt path and it
did not complain at all:

//

sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
--with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
configuring LyX version 2.0.0
checking for build type... release
checking for version suffix...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for a Python interpreter with version = 2.3.4... python
checking for python... /usr/bin/python
checking for python version... 2.5
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.5/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.5/site-packages
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking what frontend should be used for the GUI... qt4
checking for a good enough C++ compiler... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration... install-shextern size_t iconv (iconv_t
cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t
*outbytesleft);
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for gzopen in -lz... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... yes
checking for QT4_FRONTEND... yes
checking for moc-qt4... no
checking for moc... /usr/local/Trolltech/Qt-4.8.0///bin/moc
checking for uic-qt4... no
checking for uic... /usr/local/Trolltech/Qt-4.8.0///bin/uic
checking for rcc-qt4... no
checking for rcc... /usr/local/Trolltech/Qt-4.8.0///bin/rcc
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking whether we are using the GNU C Library 2 or newer... yes
checking for ranlib... ranlib
checking for simple visibility declarations... yes
checking for inline... inline
checking for size_t... yes
checking for stdint.h... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking whether integer division by zero raises SIGFPE... yes
checking for inttypes.h... yes
checking for unsigned 

Re: shared library run problem

2012-02-25 Thread Richard Heck

On 02/25/2012 08:48 AM, Sajjad wrote:

Hello


I am using an old machine and repository support went out. I recently 
updated the qt version to 4.8.0 from source.


While configuring the lyx source i am providing wiith the qt path and 
it did not complain at all:


This is just a matter of finding the headers. It doesn't have anything 
to do with which libraries the system is trying to load when LyX 
requests them. Try, as Stephan suggested:

 ldd /path/to/lyx

Richard


//

sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure 
--with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'

configuring LyX version 2.0.0
checking for build type... release
checking for version suffix...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for a Python interpreter with version = 2.3.4... python
checking for python... /usr/bin/python
checking for python version... 2.5
checking for python platform... linux2
checking for python script directory... 
${prefix}/lib/python2.5/site-packages
checking for python extension module directory... 
${exec_prefix}/lib/python2.5/site-packages

checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking what frontend should be used for the GUI... qt4
checking for a good enough C++ compiler... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration... install-shextern size_t iconv 
(iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, 
size_t *outbytesleft);

checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for gzopen in -lz... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... yes
checking for QT4_FRONTEND... yes
checking for moc-qt4... no
checking for moc... /usr/local/Trolltech/Qt-4.8.0///bin/moc
checking for uic-qt4... no
checking for uic... /usr/local/Trolltech/Qt-4.8.0///bin/uic
checking for rcc-qt4... no
checking for rcc... /usr/local/Trolltech/Qt-4.8.0///bin/rcc
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking whether we are using the GNU C Library 2 or newer... yes
checking for ranlib... ranlib
checking for simple visibility declarations... yes
checking for inline... inline
checking for size_t... yes
checking for stdint.h... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for stdlib.h... 

Re: shared library run problem

2012-02-25 Thread Sajjad
Hi

i ran the suggested diagnostics and found the following result:


sajjad@sajjad:~$ ldd /usr/local/bin/lyx
linux-vdso.so.1 = (0x7fff853ff000)
libenchant.so.1 = /usr/lib/libenchant.so.1 (0x7fd3d926b000)
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
libz.so.1 = /usr/lib/libz.so.1 (0x7fd3d8b8a000)
libQtGui.so.4 = not found
libQtCore.so.4 = not found
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
libm.so.6 = /lib/libm.so.6 (0x7fd3d85f8000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7fd3d83e)
libc.so.6 = /lib/libc.so.6 (0x7fd3d806e000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7fd3d7e52000)
libdl.so.2 = /lib/libdl.so.2 (0x7fd3d7c4e000)
libpcre.so.3 = /lib/libpcre.so.3 (0x7fd3d7a25000)
/lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)






It shows that the qt library is not found. As you have seen in the previous
post, the output of the ./configure shows that the qt library is found.
While configuring  i did mention the full qt path.

What should i check now ?


Regards
Sajjad


On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck rgh...@comcast.net wrote:

  On 02/25/2012 08:48 AM, Sajjad wrote:

 Hello


  I am using an old machine and repository support went out. I recently
 updated the qt version to 4.8.0 from source.

  While configuring the lyx source i am providing wiith the qt path and it
 did not complain at all:

  This is just a matter of finding the headers. It doesn't have anything
 to do with which libraries the system is trying to load when LyX requests
 them. Try, as Stephan suggested:
  ldd /path/to/lyx

 Richard



 //

  sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
 --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
 configuring LyX version 2.0.0
 checking for build type... release
 checking for version suffix...
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... x86_64-unknown-linux-gnu
 checking target system type... x86_64-unknown-linux-gnu
 checking what packaging should be used... posix
 checking whether to enable maintainer-specific portions of Makefiles... no
 checking for a BSD-compatible install... /usr/bin/install -c
 checking whether build environment is sane... yes
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for gawk... gawk
 checking whether make sets $(MAKE)... yes
 checking for a Python interpreter with version = 2.3.4... python
 checking for python... /usr/bin/python
 checking for python version... 2.5
 checking for python platform... linux2
 checking for python script directory...
 ${prefix}/lib/python2.5/site-packages
 checking for python extension module directory...
 ${exec_prefix}/lib/python2.5/site-packages
 checking for style of include used by make... GNU
 checking for gcc... gcc
 checking whether the C compiler works... yes
 checking for C compiler default output file name... a.out
 checking for suffix of executables...
 checking whether we are cross compiling... no
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking dependency style of gcc... gcc3
 checking how to run the C preprocessor... gcc -E
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking whether byte ordering is bigendian... no
 checking what frontend should be used for the GUI... qt4
 checking for a good enough C++ compiler... g++
 checking whether we are using the GNU C++ compiler... yes
 checking whether g++ accepts -g... yes
 checking dependency style of g++... gcc3
 checking how to run the C++ preprocessor... g++ -E
 checking for gcc... gcc
 checking whether we are using the GNU Objective C compiler... no
 checking whether gcc accepts -g... no
 checking dependency style of gcc... gcc3
 checking dependency style of gcc... (cached) gcc3
 checking for extra library directory... NONE
 checking for extra include directory... NONE
 checking for extra lib+include directory... NONE
 checking for main in -lshlwapi... no
 checking for main in -lpsapi... no
 checking for main in -lgdi32... no
 checking whether to use included boost library... 

Re: shared library run problem

2012-02-25 Thread Stephan Witt
Am 25.02.2012 um 05:57 schrieb Sajjad:

> I compiled both qt and lyx from source. The installation instructions for qt 
> did not mention anything about this issue and it is working fine.
> 
> Is there any way to send the parameter while configuring lyx so that the 
> compilation is done against the 32 -bit instead ?

Why did you compile Qt form source? Didn't you have it already installed?
I think it's better to use the system Qt and install the missing developer 
package if needed. 
You have to be sure to provide the correct version of Qt at runtime if you want 
to use your own package.
To verify that you may use "ldd /path/to/lyx" to check what Qt-libraries are 
linked at run time. 
Perhaps you have to adjust your LD_LIBRARY_PATH variable accordingly.

Stephan

> 
> I am using the 64-bit ubuntu. 
> 
> 
> 
> On Fri, Feb 24, 2012 at 6:34 PM, Richard Heck  wrote:
> On 02/24/2012 09:51 AM, Sajjad wrote:
> > hello forum,
> >
> > I just managed to compile LyX from source and it compiled fine. The qt
> > path is mentioned while configuring and configuring.
> >
> > Now when i try to run "lyx" or "lyxclient" i get the following error:
> >
> > /
> > sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
> > libQtGui.so.4: wrong ELF class: ELFCLASS32
> > 
> >
> It looks like LyX has been compiled as a 64 bit app, but what's being
> found are 32 bit libraries. I'm afraid I don't know why this would be.
> But maybe that's a clue?
> 
> Richard
> 
> 



Auto response - re:Re: shared library run problem [pfCase:2108434, pfTicket:7384782]

2012-02-25 Thread support
pfTicket: 7384782

Thank you for e-mailing the Casino Support Desk.

We have assigned your query one of our Support Consultants and you should 
receive a response soon.

While we do our best to ensure that all e-mails are responded to as quickly as 
possible, it can – on rare occasions – take a bit of time for us to get a 
response back to you

Should you urgently require a response, we would suggest that you please 
contact us via our Toll Free Numbers, listed below

Kind Regards

Casino Support

Support Hours
24 Hours a Day, 7 Days a Week 

Contact Numbers

Argentina: 08004440973
Australia: 1-800-658460
Austria: 085080
Belgium: 080049216
Canada: 18667452416
Chile: 12300207689
Cyprus: 80077315
Denmark: 80887134
Finland: 800919692
Germany: 0803370
Greece: 00 800-127-304
Hong Kong: 800-903483
Italy: 800986542
Malaysia: 1800812500
Mexico: 18669724381
Netherlands: 08000204703
New Zealand: 0800449767
Norway: 80019453
Portugal: 800-814053
Singapore: 800-1204340
Spain: 800 3000 87
Sweden: 0200-899-162
Switzerland: 081722
Thailand: 1-801-20665859
UK: 0-808-2386055


Re: shared library run problem

2012-02-25 Thread Sajjad
Hello


I am using an old machine and repository support went out. I recently
updated the qt version to 4.8.0 from source.

While configuring the lyx source i am providing wiith the qt path and it
did not complain at all:

//

sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
--with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
configuring LyX version 2.0.0
checking for build type... release
checking for version suffix...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for a Python interpreter with version >= 2.3.4... python
checking for python... /usr/bin/python
checking for python version... 2.5
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.5/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.5/site-packages
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking what frontend should be used for the GUI... qt4
checking for a good enough C++ compiler... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration... install-shextern size_t iconv (iconv_t
cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t
*outbytesleft);
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for gzopen in -lz... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... yes
checking for QT4_FRONTEND... yes
checking for moc-qt4... no
checking for moc... /usr/local/Trolltech/Qt-4.8.0///bin/moc
checking for uic-qt4... no
checking for uic... /usr/local/Trolltech/Qt-4.8.0///bin/uic
checking for rcc-qt4... no
checking for rcc... /usr/local/Trolltech/Qt-4.8.0///bin/rcc
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking whether we are using the GNU C Library 2 or newer... yes
checking for ranlib... ranlib
checking for simple visibility declarations... yes
checking for inline... inline
checking for size_t... yes
checking for stdint.h... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking whether integer division by zero raises SIGFPE... yes
checking for inttypes.h... yes
checking for unsigned 

Re: shared library run problem

2012-02-25 Thread Richard Heck

On 02/25/2012 08:48 AM, Sajjad wrote:

Hello


I am using an old machine and repository support went out. I recently 
updated the qt version to 4.8.0 from source.


While configuring the lyx source i am providing wiith the qt path and 
it did not complain at all:


This is just a matter of finding the headers. It doesn't have anything 
to do with which libraries the system is trying to load when LyX 
requests them. Try, as Stephan suggested:

> ldd /path/to/lyx

Richard


//

sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure 
--with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'

configuring LyX version 2.0.0
checking for build type... release
checking for version suffix...
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking what packaging should be used... posix
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for a Python interpreter with version >= 2.3.4... python
checking for python... /usr/bin/python
checking for python version... 2.5
checking for python platform... linux2
checking for python script directory... 
${prefix}/lib/python2.5/site-packages
checking for python extension module directory... 
${exec_prefix}/lib/python2.5/site-packages

checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking what frontend should be used for the GUI... qt4
checking for a good enough C++ compiler... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... no
checking whether gcc accepts -g... no
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for extra library directory... NONE
checking for extra include directory... NONE
checking for extra lib+include directory... NONE
checking for main in -lshlwapi... no
checking for main in -lpsapi... no
checking for main in -lgdi32... no
checking whether to use included boost library... yes
checking whether to use included MyThes library... yes
checking size of wchar_t... 4
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for iconv... yes
checking for iconv declaration... install-shextern size_t iconv 
(iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, 
size_t *outbytesleft);

checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for gzopen in -lz... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for QT4_CORE... yes
checking for QT4_FRONTEND... yes
checking for moc-qt4... no
checking for moc... /usr/local/Trolltech/Qt-4.8.0///bin/moc
checking for uic-qt4... no
checking for uic... /usr/local/Trolltech/Qt-4.8.0///bin/uic
checking for rcc-qt4... no
checking for rcc... /usr/local/Trolltech/Qt-4.8.0///bin/rcc
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking whether we are using the GNU C Library 2 or newer... yes
checking for ranlib... ranlib
checking for simple visibility declarations... yes
checking for inline... inline
checking for size_t... yes
checking for stdint.h... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for stdlib.h... 

Re: shared library run problem

2012-02-25 Thread Sajjad
Hi

i ran the suggested diagnostics and found the following result:


sajjad@sajjad:~$ ldd /usr/local/bin/lyx
linux-vdso.so.1 => (0x7fff853ff000)
libenchant.so.1 => /usr/lib/libenchant.so.1 (0x7fd3d926b000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x7fd3d9067000)
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x7fd3d8da2000)
libz.so.1 => /usr/lib/libz.so.1 (0x7fd3d8b8a000)
libQtGui.so.4 => not found
libQtCore.so.4 => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fd3d887d000)
libm.so.6 => /lib/libm.so.6 (0x7fd3d85f8000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x7fd3d83e)
libc.so.6 => /lib/libc.so.6 (0x7fd3d806e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x7fd3d7e52000)
libdl.so.2 => /lib/libdl.so.2 (0x7fd3d7c4e000)
libpcre.so.3 => /lib/libpcre.so.3 (0x7fd3d7a25000)
/lib64/ld-linux-x86-64.so.2 (0x7fd3d9476000)






It shows that the qt library is not found. As you have seen in the previous
post, the output of the ./configure shows that the qt library is found.
While configuring  i did mention the full qt path.

What should i check now ?


Regards
Sajjad


On Sat, Feb 25, 2012 at 9:49 PM, Richard Heck  wrote:

>  On 02/25/2012 08:48 AM, Sajjad wrote:
>
> Hello
>
>
>  I am using an old machine and repository support went out. I recently
> updated the qt version to 4.8.0 from source.
>
>  While configuring the lyx source i am providing wiith the qt path and it
> did not complain at all:
>
>  This is just a matter of finding the headers. It doesn't have anything
> to do with which libraries the system is trying to load when LyX requests
> them. Try, as Stephan suggested:
> > ldd /path/to/lyx
>
> Richard
>
>
>
> //
>
>  sajjad@sajjad:~/Downloads/LyX/lyx-2.0.0$ ./configure
> --with-qt4-dir='/usr/local/Trolltech/Qt-4.8.0/'
> configuring LyX version 2.0.0
> checking for build type... release
> checking for version suffix...
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking target system type... x86_64-unknown-linux-gnu
> checking what packaging should be used... posix
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for a Python interpreter with version >= 2.3.4... python
> checking for python... /usr/bin/python
> checking for python version... 2.5
> checking for python platform... linux2
> checking for python script directory...
> ${prefix}/lib/python2.5/site-packages
> checking for python extension module directory...
> ${exec_prefix}/lib/python2.5/site-packages
> checking for style of include used by make... GNU
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking dependency style of gcc... gcc3
> checking how to run the C preprocessor... gcc -E
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking whether byte ordering is bigendian... no
> checking what frontend should be used for the GUI... qt4
> checking for a good enough C++ compiler... g++
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking dependency style of g++... gcc3
> checking how to run the C++ preprocessor... g++ -E
> checking for gcc... gcc
> checking whether we are using the GNU Objective C compiler... no
> checking whether gcc accepts -g... no
> checking dependency style of gcc... gcc3
> checking dependency style of gcc... (cached) gcc3
> checking for extra library directory... NONE
> checking for extra include directory... NONE
> checking for extra lib+include directory... NONE
> checking for main in -lshlwapi... no
> checking for main 

shared library run problem

2012-02-24 Thread Sajjad
hello forum,

I just managed to compile LyX from source and it compiled fine. The qt path
is mentioned while configuring and configuring.

Now when i try to run lyx or lyxclient i get the following error:

/
sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
libQtGui.so.4: wrong ELF class: ELFCLASS32



Any hint to debug this problem.

I do not have much of an option other than compiling from source .

So i request some one in the forum to help me out to debug this problem.

Thanks
Sajjad


Re: shared library run problem

2012-02-24 Thread Richard Heck
On 02/24/2012 09:51 AM, Sajjad wrote:
 hello forum,

 I just managed to compile LyX from source and it compiled fine. The qt
 path is mentioned while configuring and configuring.

 Now when i try to run lyx or lyxclient i get the following error:

 /
 sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
 libQtGui.so.4: wrong ELF class: ELFCLASS32
 

It looks like LyX has been compiled as a 64 bit app, but what's being
found are 32 bit libraries. I'm afraid I don't know why this would be.
But maybe that's a clue?

Richard



Re: shared library run problem

2012-02-24 Thread Sajjad
I compiled both qt and lyx from source. The installation instructions for
qt did not mention anything about this issue and it is working fine.

Is there any way to send the parameter while configuring lyx so that the
compilation is done against the 32 -bit instead ?

I am using the 64-bit ubuntu.



On Fri, Feb 24, 2012 at 6:34 PM, Richard Heck rgh...@comcast.net wrote:

 On 02/24/2012 09:51 AM, Sajjad wrote:
  hello forum,
 
  I just managed to compile LyX from source and it compiled fine. The qt
  path is mentioned while configuring and configuring.
 
  Now when i try to run lyx or lyxclient i get the following error:
 
  /
  sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
  libQtGui.so.4: wrong ELF class: ELFCLASS32
  
 
 It looks like LyX has been compiled as a 64 bit app, but what's being
 found are 32 bit libraries. I'm afraid I don't know why this would be.
 But maybe that's a clue?

 Richard




shared library run problem

2012-02-24 Thread Sajjad
hello forum,

I just managed to compile LyX from source and it compiled fine. The qt path
is mentioned while configuring and configuring.

Now when i try to run lyx or lyxclient i get the following error:

/
sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
libQtGui.so.4: wrong ELF class: ELFCLASS32



Any hint to debug this problem.

I do not have much of an option other than compiling from source .

So i request some one in the forum to help me out to debug this problem.

Thanks
Sajjad


Re: shared library run problem

2012-02-24 Thread Richard Heck
On 02/24/2012 09:51 AM, Sajjad wrote:
 hello forum,

 I just managed to compile LyX from source and it compiled fine. The qt
 path is mentioned while configuring and configuring.

 Now when i try to run lyx or lyxclient i get the following error:

 /
 sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
 libQtGui.so.4: wrong ELF class: ELFCLASS32
 

It looks like LyX has been compiled as a 64 bit app, but what's being
found are 32 bit libraries. I'm afraid I don't know why this would be.
But maybe that's a clue?

Richard



Re: shared library run problem

2012-02-24 Thread Sajjad
I compiled both qt and lyx from source. The installation instructions for
qt did not mention anything about this issue and it is working fine.

Is there any way to send the parameter while configuring lyx so that the
compilation is done against the 32 -bit instead ?

I am using the 64-bit ubuntu.



On Fri, Feb 24, 2012 at 6:34 PM, Richard Heck rgh...@comcast.net wrote:

 On 02/24/2012 09:51 AM, Sajjad wrote:
  hello forum,
 
  I just managed to compile LyX from source and it compiled fine. The qt
  path is mentioned while configuring and configuring.
 
  Now when i try to run lyx or lyxclient i get the following error:
 
  /
  sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
  libQtGui.so.4: wrong ELF class: ELFCLASS32
  
 
 It looks like LyX has been compiled as a 64 bit app, but what's being
 found are 32 bit libraries. I'm afraid I don't know why this would be.
 But maybe that's a clue?

 Richard




shared library run problem

2012-02-24 Thread Sajjad
hello forum,

I just managed to compile LyX from source and it compiled fine. The qt path
is mentioned while configuring and configuring.

Now when i try to run "lyx" or "lyxclient" i get the following error:

/
sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
libQtGui.so.4: wrong ELF class: ELFCLASS32



Any hint to debug this problem.

I do not have much of an option other than compiling from source .

So i request some one in the forum to help me out to debug this problem.

Thanks
Sajjad


Re: shared library run problem

2012-02-24 Thread Richard Heck
On 02/24/2012 09:51 AM, Sajjad wrote:
> hello forum,
>
> I just managed to compile LyX from source and it compiled fine. The qt
> path is mentioned while configuring and configuring.
>
> Now when i try to run "lyx" or "lyxclient" i get the following error:
>
> /
> sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
> libQtGui.so.4: wrong ELF class: ELFCLASS32
> 
>
It looks like LyX has been compiled as a 64 bit app, but what's being
found are 32 bit libraries. I'm afraid I don't know why this would be.
But maybe that's a clue?

Richard



Re: shared library run problem

2012-02-24 Thread Sajjad
I compiled both qt and lyx from source. The installation instructions for
qt did not mention anything about this issue and it is working fine.

Is there any way to send the parameter while configuring lyx so that the
compilation is done against the 32 -bit instead ?

I am using the 64-bit ubuntu.



On Fri, Feb 24, 2012 at 6:34 PM, Richard Heck  wrote:

> On 02/24/2012 09:51 AM, Sajjad wrote:
> > hello forum,
> >
> > I just managed to compile LyX from source and it compiled fine. The qt
> > path is mentioned while configuring and configuring.
> >
> > Now when i try to run "lyx" or "lyxclient" i get the following error:
> >
> > /
> > sajjad@sajjad:~$ lyxclient: error while loading shared libraries:
> > libQtGui.so.4: wrong ELF class: ELFCLASS32
> > 
> >
> It looks like LyX has been compiled as a 64 bit app, but what's being
> found are 32 bit libraries. I'm afraid I don't know why this would be.
> But maybe that's a clue?
>
> Richard
>
>