Re: shared library run problem
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 compiler default output file name... a.out
Re: shared library run problem
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 for grep that handles
Re: shared library run problem
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 in -lpsapi... no > che
Re: shared library run problem
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... (c
Re: shared library run problem
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 l
Auto response - re:Re: shared library run problem [pfCase:2108434, pfTicket:7384782]
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
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
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 > >
Re: shared library run problem
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
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