Re: shared library run problem

[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

[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

[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

[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

[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

[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

[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
 
 

Re: shared library run problem

[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

[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

[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

[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
 
 

Re: shared library run problem

[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

[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

[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

[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
> 
> 

Re: shared library run problem

[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

[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

[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 

Re: shared library run problem

[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

[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

Re: shared library run problem

[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

[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

Re: shared library run problem

[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

[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
>
>