Re: [suse-amd64] 32-bit drivers?
I think it is a basic requirement that the drivers of a 64 bit kernel must also be 64 bit. eyc
Date: Wed, 6 Oct 2004 22:54:21 +0100 (BST) From: robin damion <duke_domani@yahoo.co.uk> To: suse-amd64@suse.com MIME-Version: 1.0 Subject: [suse-amd64] 32-bit drivers?
This is probably a silly question but, since I'm rather a newbie in most areas involved, I feel entitled to ask a few silly questions...
In the absense (as far as I'm aware) of a 64-bit driver for my graphics card (Radeon X800 Pro), can I use a 32-bit driver?
Robin.
chu@tes-mail.jpl.nasa.gov (Eugene Chu) writes:
I think it is a basic requirement that the drivers of a 64 bit kernel must also be 64 bit.
Exactly - you cannot have 32-bit and 64-bit software in one process and therefore not in the kernel, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
In message from Andreas Jaeger <aj@suse.de> (Fri, 08 Oct 2004 17:37:22 +0200):
chu@tes-mail.jpl.nasa.gov (Eugene Chu) writes:
I think it is a basic requirement that the drivers of a 64 bit kernel must also be 64 bit. Exactly - you cannot have 32-bit and 64-bit software in one process and therefore not in the kernel, I agree that it's absolutely clear. But a bit more difficult is the question of "interoperability" of 64-bit kernel drivers w/32-bit software.
For example, after translation in 32-bit mode I receive 32-bit binary application software working w/ TCP/IP stack (or I have ready 32-bit binary application). Should I hope that it'll work w/64-bit TCP/IP stack in the kernel ? Mikhail Kuzminsky Zelinsky Institute of Organic Chemistry Moscow
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Mikhail Kuzminsky wrote:
In message from Andreas Jaeger <aj@suse.de> (Fri, 08 Oct 2004 17:37:22 +0200):
chu@tes-mail.jpl.nasa.gov (Eugene Chu) writes:
I think it is a basic requirement that the drivers of a 64 bit kernel must also be 64 bit.
Exactly - you cannot have 32-bit and 64-bit software in one process and therefore not in the kernel,
I agree that it's absolutely clear. But a bit more difficult is the question of "interoperability" of 64-bit kernel drivers w/32-bit software.
For example, after translation in 32-bit mode I receive 32-bit binary application software working w/ TCP/IP stack (or I have ready 32-bit binary application). Should I hope that it'll work w/64-bit TCP/IP stack in the kernel ? Mikhail Kuzminsky Zelinsky Institute of Organic Chemistry Moscow
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
I have an Acer 1501LCe XP3000+/512M memory, 1G cache, USB 2.0, CD-RW/DVD, sound and 40G HD, 10/100/1000 ethernet BCM5788, ATI Radeon 9600. Worked OK on SuSE 9.0 and 9.1 now, 2.6.9-rc3 kernel. Devices, webcam, USB serial port. The only problem with 9.1, some apps won't build, the specific problem is that it looks in 64-bit libraries for shared and in 32-bit for static libs, hope that's fixed in 9.2. Drivers such as slmodem that contain a 32-bit proprietary module will not build with a 64-bit kernel, 32-bit plugins for mozilla will not work with the 64-bit mozilla, but are fine with 32-bit firefox. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====
Sid Boyce <sboyce@blueyonder.co.uk> writes:
[...] The only problem with 9.1, some apps won't build, the specific problem is that it looks in 64-bit libraries for shared and in 32-bit for static libs, hope that's fixed in 9.2.
That's a bug in the apps, there's nothing we can do about this. Feel free to share a simple example here on the list and let's discuss that.
Drivers such as slmodem that contain a 32-bit proprietary module will not build with a 64-bit kernel, 32-bit plugins for mozilla will not work with the 64-bit mozilla, but are fine with 32-bit firefox.
64-bit konqueror does handle 32-bit plugins since it uses a different mechanism for plugins. And you could install a 32-bit mozilla... Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger wrote:
Sid Boyce <sboyce@blueyonder.co.uk> writes:
[...] The only problem with 9.1, some apps won't build, the specific problem is that it looks in 64-bit libraries for shared and in 32-bit for static libs, hope that's fixed in 9.2.
That's a bug in the apps, there's nothing we can do about this. Feel free to share a simple example here on the list and let's discuss that.
I've tried various configure options and this is the one that works for apps that successfully built on both kde-3.2 and 3.3. ./configure --prefix=/opt/kde3 --with-qtdir=/usr/lib64/qt3 --with-qt-libraries=/usr/lib64/qt3/lib64 --with-extra-libs=/usr/lib64 --enable-libsuffix=64 I picked kmymoney as a random app as someone had complained of a problem with various apps and I was just trying to see if I could reproduce it. I just downloaded kmymoney-2.0.6 and here is the result, same as way back in early 9.1. libreposix.la is in /usr/lib64, but it keeps looking in /usr/lib even when I hardcoded it into libtool. kmymoney2.cpp:362: warning: `exists' is deprecated (declared at /opt/kde3/include/kio/netaccess.h:267) kmymoney2.cpp: In member function `void KMyMoney2App::slotKeySettings()': kmymoney2.cpp:975: warning: `configureKeys' is deprecated (declared at /opt/kde3/include/kkeydialog.h:387) if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -I/usr/include/libxml2 -DQT_THREAD_SUPPORT -D_REENTR ANT -O2 -fno-exceptions -fno-check-new -fexceptions -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cpp; \ then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi /usr/lib/qt3/bin/moc ./kstartuplogo.h -o kstartuplogo.moc.cpp if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -I/usr/include/libxml2 -DQT_THREAD_SUPPORT -D_REENTR ANT -O2 -fno-exceptions -fno-check-new -fexceptions -MT kstartuplogo.moc.o -MD -MP -MF ".deps/kstartuplogo.moc.Tpo" -c -o kstartuplogo.moc.o kstartuplogo. moc.cpp; \ then mv -f ".deps/kstartuplogo.moc.Tpo" ".deps/kstartuplogo.moc.Po"; else rm -f ".deps/kstartuplogo.moc.Tpo"; exit1; fi /usr/lib/qt3/bin/moc ./kmymoney2.h -o kmymoney2.moc.cpp if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -I/usr/include/libxml2 -DQT_THREAD_SUPPORT -D_REENTR ANT -O2 -fno-exceptions -fno-check-new -fexceptions -MT kmymoney2.moc.o -MD -MP -MF ".deps/kmymoney2.moc.Tpo" -c -o kmymoney2.moc.o kmymoney2.moc.cpp; \ then mv -f ".deps/kmymoney2.moc.Tpo" ".deps/kmymoney2.moc.Po"; else rm -f ".deps/kmymoney2.moc.Tpo"; exit 1; fi creating kmymoney2_meta_unload.cpp if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -I/usr/include/libxml2 -DQT_THREAD_SUPPORT -D_REENTR ANT -O2 -fno-exceptions -fno-check-new -fexceptions -MT kmymoney2_meta_unload.o -MD -MP-MF ".deps/kmymoney2_meta_unload.Tpo" -c -o kmymoney2_meta_unload.o kmymoney2_meta_unload.cpp; \ then mv -f ".deps/kmymoney2_meta_unload.Tpo" ".deps/kmymoney2_meta_unload.Po"; else rm -f ".deps/kmymoney2_meta_unload.Tpo"; exit 1; fi /bin/sh ../libtool --mode=link --tag=CXX g++ -O2 -fno-exceptions -fno-check-new -fexceptions -lxml2 -lz -lpthread -lm -o kmymoney2 -L/usr/X11R6/lib64 -L/ usr/lib64/qt3/lib64 -L/opt/kde3/lib -L/usr/lib64 kmymoneyutils.o kstartuplogo.o kmymoney2.o main.o kstartuplogo.moc.o kmymoney2.moc.o kmymoney2_meta_unloa d.o ./views/libviews.a ./converter/libconverter.a ./dialogs/libdialogs.a ./widgets/libwidgets.a ./mymoney/storage/libstorage.a ./mymoney/libmymoney.a -lkh tml -lkdeui -lkdecore -lqt-mt -lpng -lz -lm -lXext -lX11 -lresolv -lSM -lICE -lpthread -lresolv mkdir .libs libtool: link: cannot find the library `/usr/lib/libpcreposix.la' make[3]: *** [kmymoney2] Error 1 make[3]: Leaving directory `/ftp/oct04/kmymoney2-0.6/kmymoney2' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/ftp/oct04/kmymoney2-0.6/kmymoney2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/ftp/oct04/kmymoney2-0.6' make: *** [all] Error 2 Boycie:/ftp/oct04/kmymoney2-0.6 #
Drivers such as slmodem that contain a 32-bit proprietary module will not build with a 64-bit kernel, 32-bit plugins for mozilla will not work with the 64-bit mozilla, but are fine with 32-bit firefox.
64-bit konqueror does handle 32-bit plugins since it uses a different mechanism for plugins. And you could install a 32-bit mozilla...
Andreas
Yep, 32-bit mozilla/firefox. I shall try them in konqueror 64-bit. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====
On Sunday 10 October 2004 12:02, Sid Boyce wrote:
Andreas Jaeger wrote:
Sid Boyce <sboyce@blueyonder.co.uk> writes:
[...] The only problem with 9.1, some apps won't build, the specific problem is that it looks in 64-bit libraries for shared and in 32-bit for static libs, hope that's fixed in 9.2.
That's a bug in the apps, there's nothing we can do about this. Feel free to share a simple example here on the list and let's discuss that.
I've tried various configure options and this is the one that works for apps that successfully built on both kde-3.2 and 3.3. ./configure --prefix=/opt/kde3 --with-qtdir=/usr/lib64/qt3 --with-qt-libraries=/usr/lib64/qt3/lib64 --with-extra-libs=/usr/lib64 --enable-libsuffix=64
Having the same problem, I looked into the makefile for some apps, and there it does indeed try to link to the libs in /usr/lib instead of /usr/lib64 I did just hack the makefile, and it works then, but the --enable-libsuffix=64 and / or --with-extra-libs=/usr/lib64 might do the same trick. Now I do not know enough of autoconf / configure & Co, but I would look for the problem there. The makefile is created by configure, and configure by autoconf, so somewhere there the system does not recognize that it should link to the libs in /usr/lib64 and writes the makefile using /usr/lib instead. Therefore, Andreas, I'm not so sure if it can be blamed on the apps. It might be the autoconf / configure part of compiling the apps, and there I think you could so something, couldn't you? Regards, Matt
Matt T. wrote:
Having the same problem, I looked into the makefile for some apps, and there it does indeed try to link to the libs in /usr/lib instead of /usr/lib64
I did just hack the makefile, and it works then, but the --enable-libsuffix=64 and / or --with-extra-libs=/usr/lib64 might do the same trick.
Now I do not know enough of autoconf / configure & Co, but I would look for the problem there. The makefile is created by configure, and configure by autoconf, so somewhere there the system does not recognize that it should link to the libs in /usr/lib64 and writes the makefile using /usr/lib instead.
Therefore, Andreas, I'm not so sure if it can be blamed on the apps. It might be the autoconf / configure part of compiling the apps, and there I think you could so something, couldn't you?
I have had a fair bit of success building apps on my 9.1, but I have found that there have been instances that apps have had it hard coded to only look in /usr/lib (or /opt/kde3/lib instead of lib64). It is not always easy to find where they have done it, but after patching the source to look in the lib64 directory I have been able to get most apps to build x86_64. So far, though, most apps will build with either the --enable-libsuffix=64 or adding export LDFLAGS="-L/usr/lib64". Anyway, I believe Andreas is correct, the problem with non-building packages on x86_64 is with the apps, not a problem with the system. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
On Sunday 10 October 2004 19:41, Joe Morris (NTM) wrote:
Matt T. wrote:
Having the same problem, I looked into the makefile for some apps, and there it does indeed try to link to the libs in /usr/lib instead of /usr/lib64
I did just hack the makefile, and it works then, but the --enable-libsuffix=64 and / or --with-extra-libs=/usr/lib64 might do the same trick.
Now I do not know enough of autoconf / configure & Co, but I would look for the problem there. The makefile is created by configure, and configure by autoconf, so somewhere there the system does not recognize that it should link to the libs in /usr/lib64 and writes the makefile using /usr/lib instead.
Therefore, Andreas, I'm not so sure if it can be blamed on the apps. It might be the autoconf / configure part of compiling the apps, and there I think you could so something, couldn't you?
I have had a fair bit of success building apps on my 9.1, but I have found that there have been instances that apps have had it hard coded to only look in /usr/lib (or /opt/kde3/lib instead of lib64). It is not always easy to find where they have done it, but after patching the source to look in the lib64 directory I have been able to get most apps to build x86_64. So far, though, most apps will build with either the --enable-libsuffix=64 or adding export LDFLAGS="-L/usr/lib64". Anyway, I believe Andreas is correct, the problem with non-building packages on x86_64 is with the apps, not a problem with the system.
Yes, Joe, i see your point, and I agree. I think it is not our SuSE AMD64 system where we try to compile the apps which is doing something wrong. The apps usually come already with the configure script, and I think the error is there, which means the autoconf & friends system is responsible. And here SuSE is very well able to work with the maintainers to get it to generate configure scripts and makefiles which do also work with 64bit Linux systems. But when you say that the apps have it "hard coded to only look in /usr/lib (or /opt/kde3/lib instead of lib64)", then where is that hardcoded??? I do some programming, even in C++, using kdevelop, and I never did hardcode anywhere where to look for the libs. As far as I know, the libs are needed when the apps get linked, after compiling. The command to do so is specified in the makefile, by configure. And configure is build by autoconf & Co. Now I'm just scratching the surface of kde programming, so I might have misunderstood, but If I did get it more or less correctly, it means that somewhere in the creation of configure and / or the makefile, the correct lib path is not used. Joe, you say you patch the source, I assume you mean the c++ source, may I ask you for an example where you did patch? Thanks, Matt
-- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
And here SuSE is very well able to work with the maintainers to get it to generate configure scripts and makefiles which do also work with 64bit Linux systems.
I don't know if it's SuSE's job, but someone who knows the SuSE setup AND automake/autoconf needs to work on creating a new version of those tools that are able to run on a 64-bit machine and easily create the user's choice of 32-bit or 64-bit applications. I have not yet seen a single application which uses automake build correctly on a 64-bit machine without having to spend lots of time trying to figure out how to modify or override the incorrect settings in the generated code, especially when trying to build 32-bit libraries. I can sometimes figure out a combination of CXX, CC, CFLAGS, CXXFLAGS, LDFLAGS, linux32, --host, --enable-lib-suffix, and --with-extra-libs that it takes to get the right settings to pass all the way through libtoolize, aclocal, autoconf, autoheader, and automake but it certainly is a (%$%^& pain. Usually I end up having to override some of the Makefile settings anyway because there is no way to get the right settings to pass through the obstacle course. The autoconf family of tools are supposed to make things easier, but that's only true when they work right - and they never seem to work right in a 64-bit environment. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail
Matt T. wrote:
But when you say that the apps have it "hard coded to only look in /usr/lib (or /opt/kde3/lib instead of lib64)", then where is that hardcoded??? I do some programming, even in C++, using kdevelop, and I never did hardcode anywhere where to look for the libs.
One example was ktail. Pasted here is the diff/patch to get it to build on x86_64. --- usr/src/packages/BUILD/ktail-0.6.1/configure 2002-07-03 18:56:04.000000000 -0500 +++ home/joe/configure 2004-09-01 12:18:09.860103188 -0500 @@ -7451,8 +7451,8 @@ kde_libraries=${exec_prefix}/lib ac_kde_libraries=$exec_prefix/lib else - kde_libraries=${prefix}/lib - ac_kde_libraries=$prefix/lib + kde_libraries=${prefix}/lib64 + ac_kde_libraries=$prefix/lib64 fi else ac_kde_includes= @@ -7502,8 +7502,8 @@ So, check this please and use another prefix!" 1>&2; exit 1; } fi -kde_libdirs="/usr/lib/kde/lib /usr/local/kde/lib /usr/kde/lib /usr/lib/kde /usr/lib/kde3 /usr/lib /usr/X11R6/lib /usr/local/lib /opt/kde3/lib /opt/kde/lib /usr/X11R6/kde/lib" -test -n "$KDEDIR" && kde_libdirs="$KDEDIR/lib $KDEDIR $kde_libdirs" +kde_libdirs="/usr/lib/kde/lib /usr/local/kde/lib /usr/kde/lib /usr/lib/kde /usr/lib/kde3 /usr/lib /usr/X11R6/lib /usr/local/lib /opt/kde3/lib64 /opt/kde/lib /usr/X11R6/kde/lib" +test -n "$KDEDIR" && kde_libdirs="$KDEDIR/lib64 $KDEDIR $kde_libdirs" kde_libdirs="$ac_kde_libraries $kde_libdirs" kde_libdir=NO Sorry but this wraps.
As far as I know, the libs are needed when the apps get linked, after compiling. The command to do so is specified in the makefile, by configure. And configure is build by autoconf & Co.
I know some programs already have a configure script. Most recent kde apps can use the handy libsuffix argument.
Now I'm just scratching the surface of kde programming, so I might have misunderstood, but If I did get it more or less correctly, it means that somewhere in the creation of configure and / or the makefile, the correct lib path is not used.
Sometimes I have seen the configure scripts is built, and have seen some of those (IIRC in the autoconf directory) that needed patching because of a hard coded /usr/lib that got passed on to configure or the Makefile. An example was dansguardian. I am not a programmer though, but I know what I needed in certain instances with certain programs to get them to build (rpms). So far, I think I have had good success after making patches to the programs after tracking down any errors, but i always only make changes to the programs (I don't honestly know enough to change the tools used to build). Since I have had a good success rate this way, I would assume that it may not be the tools, but as Andreas said, the programs
Joe, you say you patch the source, I assume you mean the c++ source, may I ask you for an example where you did patch?
See above. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
On Monday 11 October 2004 03:49, Joe Morris (NTM) wrote:
Matt T. wrote:
But when you say that the apps have it "hard coded to only look in /usr/lib (or /opt/kde3/lib instead of lib64)", then where is that hardcoded??? I do some programming, even in C++, using kdevelop, and I never did hardcode anywhere where to look for the libs.
One example was ktail. Pasted here is the diff/patch to get it to build on x86_64.
--- usr/src/packages/BUILD/ktail-0.6.1/configure 2002-07-03 18:56:04.000000000 -0500 +++ home/joe/configure 2004-09-01 12:18:09.860103188 -0500 [snip]
As far as I know, the libs are needed when the apps get linked, after compiling. The command to do so is specified in the makefile, by configure. And configure is build by autoconf & Co.
I know some programs already have a configure script. Most recent kde apps can use the handy libsuffix argument.
Now I'm just scratching the surface of kde programming, so I might have misunderstood, but If I did get it more or less correctly, it means that somewhere in the creation of configure and / or the makefile, the correct lib path is not used.
Sometimes I have seen the configure scripts is built, and have seen some of those (IIRC in the autoconf directory) that needed patching because of a hard coded /usr/lib that got passed on to configure or the Makefile. An example was dansguardian. I am not a programmer though, but I know what I needed in certain instances with certain programs to get them to build (rpms). So far, I think I have had good success after making patches to the programs after tracking down any errors, but i always only make changes to the programs (I don't honestly know enough to change the tools used to build). Since I have had a good success rate this way, I would assume that it may not be the tools, but as Andreas said, the programs
Joe, you say you patch the source, I assume you mean the c++ source, may I ask you for an example where you did patch?
See above.
Joe, according to this example you are patching the configure script, and not the c++ source code. When I program with kdevelop, I do write c++ code, but I do not write the configure script. The configure script is created for me by kdevelop, which uses autoconf & friends to do the work here. Usually when we download an app as .gz or .bz etc., the configure script is included. So yes, it looks as if it is the app and the programmer of the app, but no, I think in most cases the configure script included with the app had been created more or less automatically, using the tool. That is why I think that these tools need to get fixed, so they produce a configure script which works on 32 bit and on 64 bit systems. Regards, Matt
-- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
Matt T. wrote:
Joe, you say you patch the source, I assume you mean the c++ source, may I ask you for an example where you did patch?
See above.
Joe, according to this example you are patching the configure script, and not the c++ source code.
As the configure script (in this case) came with the source, I was patching the program source (i.e. it wasn't getting built automatically during the build process), though you are correct it was not c++ code (above my ability, I am not a programmer). BTW, since I know dansguardian is a c++ program, here is a part of the patch I needed to fix a hardcoded path. --- autoconf/linux.in.orig 2004-09-02 23:31:27.470442186 -0500 +++ autoconf/linux.in 2004-09-02 23:32:57.838906818 -0500 @@ -14,7 +14,7 @@ HTMLTemplate.o LanguageContainer.o DynamicURLList.o ImageContainer.o \ FOptionContainer.o ListManager.o md5.o -LIBS = /usr/lib/libz.a +LIBS = /usr/lib64/libz.a PROG = dansguardian INSTALLFILES = dansguardian dansguardian.conf dansguardian.sysv \ bannedphraselist exceptionsitelist dansguardian.pl \ I don't know what tool was used to produce these files, but this is not old code, but these files were a part of the source tarball.
When I program with kdevelop, I do write c++ code, but I do not write the configure script. The configure script is created for me by kdevelop, which uses autoconf & friends to do the work here.
Which may work fine. Lots of programs will build without patching. Perhaps my conjecture that if most build with no patches, and some build after some hardcoded paths get changed in the program source (via a patch via a spec file) albeit not the c++ code, that the tools would not be at fault, may be a wrong assumption. I truly do not know enough to judge the tools more objectively. It could be old programs built with an outdated autoconf, libtool, etc., I don't know. I just wanted to make sure that the effort to fix any problems were attacking the correct source of the problem, otherwise it would just waste effort and time.
Usually when we download an app as .gz or .bz etc., the configure script is included. So yes, it looks as if it is the app and the programmer of the app, but no, I think in most cases the configure script included with the app had been created more or less automatically, using the tool.
Which makes me wonder, is the tools included with our SuSE that may be at fault, or the tools on the program developer's system? I am not judging your code BTW, just speaking from my limited experience.
That is why I think that these tools need to get fixed, so they produce a configure script which works on 32 bit and on 64 bit systems.
agreed, but it might not be the tools we possess. I know SuSE tests and patches a lot of programs and it might be possible that their particular versions do work. I realize I could be all wrong, though, so take my ramblings as just that. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
Matt T. wrote:
On Sunday 10 October 2004 12:02, Sid Boyce wrote:
Andreas Jaeger wrote:
Sid Boyce <sboyce@blueyonder.co.uk> writes:
[...] The only problem with 9.1, some apps won't build, the specific problem is that it looks in 64-bit libraries for shared and in 32-bit for static libs, hope that's fixed in 9.2.
That's a bug in the apps, there's nothing we can do about this. Feel free to share a simple example here on the list and let's discuss that.
I've tried various configure options and this is the one that works for apps that successfully built on both kde-3.2 and 3.3. ./configure --prefix=/opt/kde3 --with-qtdir=/usr/lib64/qt3 --with-qt-libraries=/usr/lib64/qt3/lib64 --with-extra-libs=/usr/lib64 --enable-libsuffix=64
Having the same problem, I looked into the makefile for some apps, and there it does indeed try to link to the libs in /usr/lib instead of /usr/lib64
I did just hack the makefile, and it works then, but the --enable-libsuffix=64 and / or --with-extra-libs=/usr/lib64 might do the same trick.
Now I do not know enough of autoconf / configure & Co, but I would look for the problem there. The makefile is created by configure, and configure by autoconf, so somewhere there the system does not recognize that it should link to the libs in /usr/lib64 and writes the makefile using /usr/lib instead.
Therefore, Andreas, I'm not so sure if it can be blamed on the apps. It might be the autoconf / configure part of compiling the apps, and there I think you could so something, couldn't you?
Regards, Matt
Seems that autoconf/configure don't do a thorough job. I changed any instance of lib to lib64 in configure,libtool, then in Makefiles I hardcoded paths as errors occurred (kmymoney2 and kmymoney2/html only I think) and finally it built, checkinstall, rpm -Uvh kmymoney2-0.6-1.x86_64.rpm and it all works. --- configure 2004-06-06 18:13:46.000000000 +0100 +++ ../../kmymoney2-0.6/configure 2004-10-11 00:09:58.959572194 +0100 @@ -345,7 +345,7 @@ sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' -libdir='${exec_prefix}/lib' +libdir='${exec_prefix}/lib64' includedir='${prefix}/include' oldincludedir='/usr/include' infodir='${prefix}/info' --- libtool 2004-10-11 01:32:14.798681943 +0100 +++ ../../kmymoney2-0.6/libtool 2004-10-11 00:27:58.010227660 +0100 @@ -297,10 +297,10 @@ link_all_deplibs=unknown # Compile-time system search path for libraries -sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib" +sys_lib_search_path_spec="/lib64 /usr/lib64 /usr/local/lib64" # Run-time system search path for libraries -sys_lib_dlsearch_path_spec="/lib /usr/lib" +sys_lib_dlsearch_path_spec="/lib64 /usr/lib64" # Fix the shell variable $srcfile for the compiler. fix_srcfile_path="" @@ -2023,7 +2023,7 @@ name=`$echo "X$deplib" | $Xsed -e 's/^-l//'` for searchdir in $newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path; do # Search the libtool library - lib="$searchdir/lib${name}.la" + lib="/usr/lib64/lib${name}.la" if test -f "$lib"; then found=yes break --- kmymoney2/Makefile 2004-10-11 01:32:29.557406435 +0100 +++ ../../kmymoney2-0.6/kmymoney2/Makefile 2004-10-11 00:35:59.676030103 +0100 @@ -119,15 +119,15 @@ DISTFILES= $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) $(KDE_DIST) -ACLOCAL = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run aclocal-1.8 +ACLOCAL = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run aclocal-1.8 AMDEP_FALSE = # AMDEP_TRUE = -AMTAR = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run tar +AMTAR = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run tar ARTSCCONFIG = /opt/kde3/bin/artsc-config -AUTOCONF = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run autoconf +AUTOCONF = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run autoconf AUTODIRS = -AUTOHEADER = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run autoheader -AUTOMAKE = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run automake-1.8 +AUTOHEADER = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run autoheader +AUTOMAKE = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run automake-1.8 AWK = gawk CC = gcc CCDEPMODE = depmode=gcc3 @@ -211,7 +211,7 @@ LIB_XEXT = -lXext LN_S = ln -s LTLIBOBJS = -MAKEINFO = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run makeinfo +MAKEINFO = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run makeinfo MCOPIDL = /opt/kde3/bin/mcopidl MEINPROC = /opt/kde3/bin/meinproc MOC = /usr/lib/qt3/bin/moc @@ -259,7 +259,7 @@ ac_ct_RANLIB = ranlib ac_ct_STRIP = strip all_includes = -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -all_libraries = -L/usr/X11R6/lib64 -L/usr/lib64/qt3/lib64 -L/opt/kde3/lib -L/usr/lib64 +all_libraries = -L/usr/X11R6/lib64 -L/usr/lib64/qt3/lib64 -L/opt/kde3/lib64 -L/usr/lib64 am__fastdepCC_FALSE = # am__fastdepCC_TRUE = am__fastdepCXX_FALSE = # @@ -282,7 +282,7 @@ host_vendor = unknown includedir = ${prefix}/include infodir = ${prefix}/info -install_sh = /ftp/oct04/XXX/kmymoney2-0.6/admin/install-sh +install_sh = /ftp/oct04/kmymoney2-0.6/admin/install-sh kde_appsdir = ${prefix}/share/applnk kde_bindir = ${exec_prefix}/bin kde_confdir = ${prefix}/share/config @@ -290,7 +290,7 @@ kde_htmldir = ${prefix}/share/doc/HTML kde_icondir = ${prefix}/share/icons kde_includes = /opt/kde3/include -kde_libraries = /opt/kde3/lib +kde_libraries = /opt/kde3/lib64 kde_libs_htmldir = /opt/kde3/share/doc/HTML kde_libs_prefix = /opt/kde3 kde_locale = ${prefix}/share/locale @@ -304,7 +304,7 @@ kde_templatesdir = ${prefix}/share/templates kde_wallpaperdir = ${prefix}/share/wallpapers kde_widgetdir = ${exec_prefix}/lib/kde3/plugins/designer -libdir = ${exec_prefix}/lib +libdir = ${exec_prefix}/lib64 libexecdir = ${exec_prefix}/libexec localstatedir = ${prefix}/var mandir = ${prefix}/man --- kmymoney2/html/Makefile 2004-10-11 01:32:29.590405792 +0100 +++ ../../kmymoney2-0.6/kmymoney2/html/Makefile 2004-10-11 00:33:26.000000000 +0100 @@ -58,15 +58,15 @@ DISTFILES= $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) $(KDE_DIST) -ACLOCAL = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run aclocal-1.8 +ACLOCAL = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run aclocal-1.8 AMDEP_FALSE = # AMDEP_TRUE = -AMTAR = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run tar +AMTAR = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run tar ARTSCCONFIG = /opt/kde3/bin/artsc-config -AUTOCONF = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run autoconf +AUTOCONF = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run autoconf AUTODIRS = -AUTOHEADER = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run autoheader -AUTOMAKE = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run automake-1.8 +AUTOHEADER = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run autoheader +AUTOMAKE = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run automake-1.8 AWK = gawk CC = gcc CCDEPMODE = depmode=gcc3 @@ -103,7 +103,7 @@ KDE_CXXFLAGS = KDE_EXTRA_RPATH = -R /usr/lib64 KDE_INCLUDES = -I/opt/kde3/include -KDE_LDFLAGS = -L/opt/kde3/lib +KDE_LDFLAGS = -L/opt/kde3/lib64 KDE_MT_LDFLAGS = KDE_MT_LIBS = -lpthread KDE_PLUGIN = -avoid-version -module -no-undefined $(KDE_RPATH) $(KDE_MT_LDFLAGS) @@ -150,7 +150,7 @@ LIB_XEXT = -lXext LN_S = ln -s LTLIBOBJS = -MAKEINFO = ${SHELL} /ftp/oct04/XXX/kmymoney2-0.6/admin/missing --run makeinfo +MAKEINFO = ${SHELL} /ftp/oct04/kmymoney2-0.6/admin/missing --run makeinfo MCOPIDL = /opt/kde3/bin/mcopidl MEINPROC = /opt/kde3/bin/meinproc MOC = /usr/lib/qt3/bin/moc @@ -198,7 +198,7 @@ ac_ct_RANLIB = ranlib ac_ct_STRIP = strip all_includes = -I/opt/kde3/include -I/usr/lib/qt3/include -I/usr/X11R6/include -all_libraries = -L/usr/X11R6/lib64 -L/usr/lib64/qt3/lib64 -L/opt/kde3/lib -L/usr/lib64 +all_libraries = -L/usr/X11R6/lib64 -L/usr/lib64/qt3/lib64 -L/opt/kde3/lib64 -L/usr/lib64 am__fastdepCC_FALSE = # am__fastdepCC_TRUE = am__fastdepCXX_FALSE = # @@ -221,7 +221,7 @@ host_vendor = unknown includedir = ${prefix}/include infodir = ${prefix}/info -install_sh = /ftp/oct04/XXX/kmymoney2-0.6/admin/install-sh +install_sh = /ftp/oct04/kmymoney2-0.6/admin/install-sh kde_appsdir = ${prefix}/share/applnk kde_bindir = ${exec_prefix}/bin kde_confdir = ${prefix}/share/config @@ -229,7 +229,7 @@ kde_htmldir = ${prefix}/share/doc/HTML kde_icondir = ${prefix}/share/icons kde_includes = /opt/kde3/include -kde_libraries = /opt/kde3/lib +kde_libraries = /opt/kde3/lib64 kde_libs_htmldir = /opt/kde3/share/doc/HTML kde_libs_prefix = /opt/kde3 kde_locale = ${prefix}/share/locale @@ -243,7 +243,7 @@ kde_templatesdir = ${prefix}/share/templates kde_wallpaperdir = ${prefix}/share/wallpapers kde_widgetdir = ${exec_prefix}/lib/kde3/plugins/designer -libdir = ${exec_prefix}/lib +libdir = ${exec_prefix}/lib64 libexecdir = ${exec_prefix}/libexec localstatedir = ${prefix}/var mandir = ${prefix}/man Apologies for the long post, there's stuff I could trim, it's 01:52 BST. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer =====LINUX ONLY USED HERE=====
"Mikhail Kuzminsky" <kus@free.net> writes:
In message from Andreas Jaeger <aj@suse.de> (Fri, 08 Oct 2004 17:37:22 +0200):
chu@tes-mail.jpl.nasa.gov (Eugene Chu) writes:
I think it is a basic requirement that the drivers of a 64 bit kernel must also be 64 bit. Exactly - you cannot have 32-bit and 64-bit software in one process and therefore not in the kernel, I agree that it's absolutely clear. But a bit more difficult is the question of "interoperability" of 64-bit kernel drivers w/32-bit software.
For example, after translation in 32-bit mode I receive 32-bit binary application software working w/ TCP/IP stack (or I have ready 32-bit binary application). Should I hope that it'll work w/64-bit TCP/IP stack in the kernel ?
The kernel is in a separate process and a 32-bit application can call the 64-bit kernel - there's some glue between to convert the arguments - and just those. The kernel will then execute in 64-bit on behalf of the 32-bit application, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
participants (7)
-
Andreas Jaeger -
chu＠tes-mail.jpl.nasa.gov -
Joe Morris (NTM) -
Matt T. -
Mikhail Kuzminsky -
Sid Boyce -
Steve Potter