Hello to all, after updating my amd64-box to suse 9.1 (uname -a: Linux sepia 2.6.4-52-default #1 Wed Apr 7 02:15:23 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) my kylix 3 don't start anymore. The error message is: --------------- /opt/kylix3/bin/delphi: relocation error: /opt/kylix3/bin/libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ---------------- Anybody knows what to do ? detlef oertel
On Sun, May 02, 2004 at 09:20:06PM +0200, detlef oertel wrote:
Hello to all,
after updating my amd64-box to suse 9.1 (uname -a: Linux sepia 2.6.4-52-default #1 Wed Apr 7 02:15:23 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) my kylix 3 don't start anymore. The error message is: --------------- /opt/kylix3/bin/delphi: relocation error: /opt/kylix3/bin/libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ----------------
Anybody knows what to do ?
Try export LD_ASSUME_KERNEL=2.4.21 before starting it. Ciao, Marcus
Marcus Meissner <meissner@suse.de> writes:
On Sun, May 02, 2004 at 09:20:06PM +0200, detlef oertel wrote:
Hello to all,
after updating my amd64-box to suse 9.1 (uname -a: Linux sepia 2.6.4-52-default #1 Wed Apr 7 02:15:23 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) my kylix 3 don't start anymore. The error message is: --------------- /opt/kylix3/bin/delphi: relocation error: /opt/kylix3/bin/libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ----------------
Anybody knows what to do ?
Try export LD_ASSUME_KERNEL=2.4.21 before starting it.
Which uses the i586 glibc and not the i686 one... The problem is that kylix is broken, it should have never used errno - and glibc has removed support for that... 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
On Sun, May 02, 2004 at 09:46:45PM +0200, Andreas Jaeger wrote:
Marcus Meissner <meissner@suse.de> writes:
On Sun, May 02, 2004 at 09:20:06PM +0200, detlef oertel wrote:
Hello to all,
after updating my amd64-box to suse 9.1 (uname -a: Linux sepia 2.6.4-52-default #1 Wed Apr 7 02:15:23 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) my kylix 3 don't start anymore. The error message is: --------------- /opt/kylix3/bin/delphi: relocation error: /opt/kylix3/bin/libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ----------------
Anybody knows what to do ?
Try export LD_ASSUME_KERNEL=2.4.21 before starting it.
Which uses the i586 glibc and not the i686 one...
The problem is that kylix is broken, it should have never used errno - and glibc has removed support for that...
Correct. In that case, you have to use i386 libraries from 9.0 ... Ciao, Marcus
Marcus Meissner <meissner@suse.de> writes:
On Sun, May 02, 2004 at 09:46:45PM +0200, Andreas Jaeger wrote:
Marcus Meissner <meissner@suse.de> writes:
On Sun, May 02, 2004 at 09:20:06PM +0200, detlef oertel wrote:
Hello to all,
after updating my amd64-box to suse 9.1 (uname -a: Linux sepia 2.6.4-52-default #1 Wed Apr 7 02:15:23 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) my kylix 3 don't start anymore. The error message is: --------------- /opt/kylix3/bin/delphi: relocation error: /opt/kylix3/bin/libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ----------------
Anybody knows what to do ?
Try export LD_ASSUME_KERNEL=2.4.21 before starting it.
Which uses the i586 glibc and not the i686 one...
The problem is that kylix is broken, it should have never used errno - and glibc has removed support for that...
Correct.
In that case, you have to use i386 libraries from 9.0 ...
The i586 libs should handle that, we added some backward code to only that version... 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
Hello, thank you, but I don't understand what it means to me, that 'i586 libs should handle that'.... however: The 'export LD_ASSUME_KERNEL=2.4.21' stops the first error but ends in a runtime error: ------------- detlef@sepia:~> export LD_ASSUME_KERNEL=2.4.21 detlef@sepia:~> startdelphi Runtime error 234 at 56A3E9B7 detlef@sepia:~> ------------ The problem 'i586 against i686 libs' sounds to my ears like: this isn't a '64Bit problem' but an 'update to suse 9.1 with kernel 2.6' problem. Is this correct ? How going on from here ? detlef oertel Andreas Jaeger wrote:
Marcus Meissner <meissner@suse.de> writes:
On Sun, May 02, 2004 at 09:46:45PM +0200, Andreas Jaeger wrote:
Marcus Meissner <meissner@suse.de> writes:
On Sun, May 02, 2004 at 09:20:06PM +0200, detlef oertel wrote:
Hello to all,
after updating my amd64-box to suse 9.1 (uname -a: Linux sepia 2.6.4-52-default #1 Wed Apr 7 02:15:23 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux) my kylix 3 don't start anymore. The error message is: --------------- /opt/kylix3/bin/delphi: relocation error: /opt/kylix3/bin/libwine.borland.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference ----------------
Anybody knows what to do ?
Try export LD_ASSUME_KERNEL=2.4.21 before starting it.
Which uses the i586 glibc and not the i686 one...
The problem is that kylix is broken, it should have never used errno - and glibc has removed support for that...
Correct.
In that case, you have to use i386 libraries from 9.0 ...
The i586 libs should handle that, we added some backward code to only that version...
Andreas
detlef oertel <oertel@uib.de> writes:
Hello,
thank you, but I don't understand what it means to me, that 'i586 libs should handle that'....
however: The 'export LD_ASSUME_KERNEL=2.4.21' stops the first error but ends in a runtime error: ------------- detlef@sepia:~> export LD_ASSUME_KERNEL=2.4.21 detlef@sepia:~> startdelphi Runtime error 234 at 56A3E9B7 detlef@sepia:~> ------------
The problem 'i586 against i686 libs' sounds to my ears like: this isn't a '64Bit problem' but an 'update to suse 9.1 with kernel 2.6' problem. Is this correct ?
kylix is a 32-bit application and therefore it uses the 32-bit libaries. We have to set of 32-bit glibc libraries: - i586 ones - i686 ones The difference is in threading support (read the manual on Update) and also the i586 ones contain some compatibility code for broken applications. If setting LD_ASSUME_KERNEL does not help, then kylix is really broken, 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
detlef oertel schrieb:
detlef@sepia:~> startdelphi Runtime error 234 at 56A3E9B7
I got runtime errors 234 too on SuSE 9.0 AMD64. After cp /usr/lib64/gconv/gconv-modules /usr/libgconv/ the error was gone. (Was caused due to a bug in the SuSE Linux distribution) HTH Willi
* Willibald Krenn (Willibald.Krenn@gmx.at) [20040503 17:08]:
I got runtime errors 234 too on SuSE 9.0 AMD64. After cp /usr/lib64/gconv/gconv-modules /usr/libgconv/ the error was gone. (Was caused due to a bug in the SuSE Linux distribution)
But that's a totally different problem! Philipp -- Philipp Thomas <pth@suse.de> SUSE LINUX AG, Maxfeldstr. 5, D-90409 Nuremberg, Germany
Philipp Thomas schrieb:
* Willibald Krenn (Willibald.Krenn@gmx.at) [20040503 17:08]:
I got runtime errors 234 too on SuSE 9.0 AMD64. After cp /usr/lib64/gconv/gconv-modules /usr/libgconv/ the error was gone. (Was caused due to a bug in the SuSE Linux distribution)
But that's a totally different problem!
I really don't understand what you are trying to say. A runtime error 234 in Kylix is always based on some sort of "234 { reCodesetConversion }" problem. (Indicates most of the time that glibc-locale-32bit has to be installed.) This is ridiculous: Windows XP still runs DOS, 16 bit Windows and Windows 95 programs mostly without a hitch. On Linux we have to throw away our applications every other year, just because developers don't care for backward compatibility. (Thank god, we have Microsoft!) Linux will never conquer the desktop, Willi
On Mon, May 03, Willibald Krenn wrote:
This is ridiculous: Windows XP still runs DOS, 16 bit Windows and Windows 95 programs mostly without a hitch. On Linux we have to throw away our applications every other year, just because developers don't care for backward compatibility. (Thank god, we have Microsoft!)
You wrote it: "mostly without a hitch". I still can use Applixware from good old libc.so.5 days (I think this application is about 5-6 years old). It works. Nothing more. The programmers made a good job and wrote an application without using internal interfaces or something else. If your Windows application uses internal interfaces or is build in a wrong way, it will fail with the next Windows version, too. The same is true for Linux. There is no difference. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
I still can use Applixware from good old libc.so.5 days (I think this application is about 5-6 years old). It works. Nothing more. The programmers made a good job and wrote an application without using internal interfaces or something else.
Also an a.out linux distribution (SuSE 4.2) runs nicely on the x86-64 kernel (except for GNU emacs 18 who doesn't like 4GB of address space) I also ran some very old a.out binaries from Linux prehistory (~1992) successfully on the x86-64 kernel.
If your Windows application uses internal interfaces or is build in a wrong way, it will fail with the next Windows version, too. The same is true for Linux. There is no difference.
Win64 dropped supported for 16bit Windows programs. Wine on x86-64 linux runs them still fine. -Andi
Andi Kleen schrieb:
Also an a.out linux distribution (SuSE 4.2) runs nicely on the x86-64 kernel (except for GNU emacs 18 who doesn't like 4GB of address space) I also ran some very old a.out binaries from Linux prehistory (~1992) successfully on the x86-64 kernel.
Hmm, impressive! If only all components of GNU/Linux would be tested such comprehensively.
Win64 dropped supported for 16bit Windows programs. Wine on x86-64 linux runs them still fine.
What a pitty that a change in glibc broke wine... (and thus probably Kylix) http://www.kerneltraffic.org/wine/wn20030131_155.html - point 2 Willi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2004 12:52 pm, Willibald Krenn wrote:
Andi Kleen schrieb:
Also an a.out linux distribution (SuSE 4.2) runs nicely on the x86-64 kernel (except for GNU emacs 18 who doesn't like 4GB of address space) I also ran some very old a.out binaries from Linux prehistory (~1992) successfully on the x86-64 kernel.
Hmm, impressive! If only all components of GNU/Linux would be tested such comprehensively.
Win64 dropped supported for 16bit Windows programs. Wine on x86-64 linux runs them still fine.
What a pitty that a change in glibc broke wine... (and thus probably Kylix)
http://www.kerneltraffic.org/wine/wn20030131_155.html - point 2
Key phrase: "Basically they offer significant threading improvements in order to solve the " C10K" problem." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAlpx9rXAtDXHWsekRAkh0AJ9DYnNn+TgibI6iJpzksWa9WGZlOACfWzWJ PVs27CNq1BEdx/tKBVoj/SI= =xbf2 -----END PGP SIGNATURE-----
"Basically they offer significant threading improvements in order to solve the " C10K" problem."
Sure it has a positive side too - Linux seems to be a very good choice for Servers today.. Ok, to stop the thread I've started right here: I would love to see Linux getting on the Desktop! Otherwise I wouldn't have purchased a development tool that produces desktop applications for Linux (and is now several generations behind). Unfortunately it seems that no one (except IBM and SCO perhaps ;-) ) has come up with a concept of making money from Linux based applications. AFIU costs for testing in all possible distribution, kernel/glib combinations plus supplying frequent updates is too high and sale figures too low. Willi
On May 3, 2004 02:56 pm, Willibald Krenn wrote:
"Basically they offer significant threading improvements in order to solve the " C10K" problem."
Sure it has a positive side too - Linux seems to be a very good choice for Servers today..
Oh, so we should just ignore the little problems that happen on the server and instead go with the "no-fixes-but-perfectly-backward-compatible" way for the desktop? I really appreciate it when users are not separated into categories of extremely low and extremely high priority, independent of their platform and demands. IM very HO the developers did the right thing(afaics now) and if there's a proprietary vendor who doesn't care about what they have to say/do, it's his own damn fault when their software stops working properly as here. Complain just to Borland, please. I'm pretty sure they knew what kind of market they're getting into.
Ok, to stop the thread I've started right here: I would love to see Linux getting on the Desktop! Otherwise I wouldn't have purchased a development tool that produces desktop applications for Linux (and is now several generations behind). Unfortunately it seems that no one (except IBM and SCO perhaps ;-) ) has come up with a concept of making money from Linux based applications.
I wouldn't even try to guess that before actually doing some research.
AFIU costs for testing in all possible distribution, kernel/glib combinations plus supplying frequent updates is too high and sale figures too low.
Why bother, then?
tisdag 04 maj 2004 00:24 skrev Sergei Klink:
AFIU costs for testing in all possible distribution, kernel/glib combinations plus supplying frequent updates is too high and sale figures too low.
Why bother, then?
Fact of the matter is, that companies, that used to be the biggest market ... are using product copies, or cheaper alternatives. This applies to Windows, as well as Linux. The biggest "income" market for Windows is still the fact, that most computers come with it pre-installed. It has nothing to do with Windows being more stable than Linux, as we all know, if not by experience than by word, the famous blue screen, guru meditation, bombs and runtime errors on other platforms. On occasion, I go over to Windows (which is now Windows XP 64bit), to develop some windows application (in delphi) but only because the customer uses Windows and thinks he can't use anything but MS Excel, MS Word, etc. Not because these apps are superior, as the customer doesn't use 10% of their potential. This customer, is not a customer to make future plans on ... it's a customer to ignore, and what Linux needs to do is to introduce a new concept, not try and follow in the footsteps of Microsoft. Because 70% of the customers that use Windows, wouldn't buy it nor any of it's based products if it wasn't included with their computers ... and those companies that rely on Windows (small to medium sized) do that because to skip the learning curve of the user, and because they can run a pirated copy of most of the products anyways and copy to older machines, etc. Linux should, focus less on compatibility imo ... especially these days, when every script kiddie is writing viruses. Having an OS, that's "out of their reach" is a plus ... and any customer, whose got any wit at all, knows this. And these are the paying customers, imnsho ... not the other customer base. As I don't see Linux being pre-installed on home computers anytime soon. Yet, the readability of Linux also ensures that the learning curve is not too steep for the average user.
On Mon, May 03, 2004 at 08:52:28PM +0200, Willibald Krenn wrote:
Andi Kleen schrieb:
Also an a.out linux distribution (SuSE 4.2) runs nicely on the x86-64 kernel (except for GNU emacs 18 who doesn't like 4GB of address space) I also ran some very old a.out binaries from Linux prehistory (~1992) successfully on the x86-64 kernel.
Hmm, impressive! If only all components of GNU/Linux would be tested such comprehensively.
Win64 dropped supported for 16bit Windows programs. Wine on x86-64 linux runs them still fine.
What a pitty that a change in glibc broke wine... (and thus probably Kylix)
http://www.kerneltraffic.org/wine/wn20030131_155.html - point 2
WINE works just fine on AMD64, the code has been fixed. Ciao, Marcus
Thorsten Kukuk schrieb:
I still can use Applixware from good old libc.so.5 days (I think this application is about 5-6 years old). It works. Nothing more. The programmers made a good job and wrote an application without using internal interfaces or something else.
I guess the internal interfaces (?errno issue?) were used by the wine module Borland used to port the IDE to Linux. BTW: If someone from outside can use my _internal_ interfaces, then these interfaces aren't really internal, are they? Furthermore it's difficult to compare a RAD-IDE that has integrated debugger support with some 'normal' userland application..
If your Windows application uses internal interfaces or is build in a wrong way, it will fail with the next Windows version, too. The same is true for Linux. There is no difference.
On Linux you still have to know how you have to set up your work-arounds (environment vars, all sorts of 'deprecated' packages,..) - mostly due to the lack of standards. You simply can not compare GNU/Linux and Windows in terms of respecting backward compatibility (and end-user friendliness). My Windows XP still runs a (closed source) DirectX game (chopper sim; 3D) from 1996 today! Try that on GNU/Linux - if you manage to find ... Sorry for the off-topic, Willi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 3, 2004 12:36 pm, Willibald Krenn wrote:
Thorsten Kukuk schrieb:
I still can use Applixware from good old libc.so.5 days (I think this application is about 5-6 years old). It works. Nothing more. The programmers made a good job and wrote an application without using internal interfaces or something else.
I guess the internal interfaces (?errno issue?) were used by the wine module Borland used to port the IDE to Linux. BTW: If someone from outside can use my _internal_ interfaces, then these interfaces aren't really internal, are they? Furthermore it's
If they're marked as internal in the documentation, the authors really meant that it's not a good idea to use them, but someone might still have a good use for them, so if someone does, they should know what they're doing. Certainly not a good thing to do for a closed-source product. On a side note, using wine to port apps of this size is kind of cheating to me :)
difficult to compare a RAD-IDE that has integrated debugger support with some 'normal' userland application..
If your Windows application uses internal interfaces or is build in a wrong way, it will fail with the next Windows version, too. The same is true for Linux. There is no difference.
On Linux you still have to know how you have to set up your work-arounds (environment vars, all sorts of 'deprecated' packages,..) - mostly due to the lack of standards.
You simply can not compare GNU/Linux and Windows in terms of respecting backward compatibility (and end-user friendliness). My Windows XP still runs a (closed source) DirectX game (chopper sim; 3D) from 1996 today! Try that on GNU/Linux - if you manage to find
You're also forgetting that GNU/Linux isn't that old - DOS has been around for longer and had time to establish itself. Sure, you can do things like static-linking about as much as you can(which is what a lot of windows software tends to be), but I'm sure you realize it has lots of downsides, too. Having most of the software open-source on our systems, there is quite an advantage of improving things and bugfixing without thinking too much about backwards compatibility - I think that's a fairly positive thing. Sure, it would be good to have it a level similar to winxp(from end-user point of view) - but that might come at price which I wouldn't want to pay, either. Besides, winxp isn't that great at it - I have a few win95 apps(mostly quite simple, one of them some sort of medical database, others also had a little specific uses) one of which did refuse to run in winxp(no matter what options), and the other had severe problems with the localized interface(both of them work fine in wine). Don't get me wrong, I'm not a winxp user :) And I don't dualboot anymore :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAlpvBrXAtDXHWsekRAi/fAJ9ISl8cz1Hx1FizuOue7DgoeppT7ACfU6qM R7AGcM13VUUuzz+GkmWR78o= =uovB -----END PGP SIGNATURE-----
On Mon, 2004-05-03 at 18:11, Willibald Krenn wrote:
Philipp Thomas schrieb:
* Willibald Krenn (Willibald.Krenn@gmx.at) [20040503 17:08]:
I got runtime errors 234 too on SuSE 9.0 AMD64. After cp /usr/lib64/gconv/gconv-modules /usr/libgconv/ the error was gone. (Was caused due to a bug in the SuSE Linux distribution)
But that's a totally different problem!
I really don't understand what you are trying to say. A runtime error 234 in Kylix is always based on some sort of "234 { reCodesetConversion }" problem. (Indicates most of the time that glibc-locale-32bit has to be installed.)
This is ridiculous: Windows XP still runs DOS, 16 bit Windows and Windows 95 programs mostly without a hitch. On Linux we have to throw away our applications every other year, just because developers don't care for backward compatibility. (Thank god, we have Microsoft!)
Linux will never conquer the desktop, Willi I have come across certain documents created on later versions of Windows that can't be opened in Windows 95. You can use Microsoft or whatever you like, no one will beat you up for choosing what you like. "Linux will never ....", "Linux won't ....", "Linux can't", etc. never stopped the guys from writing the code and not caring one bit what gets written or said and I don't see them ever giving up and sitting sadly down with cans of beer in front of a TV set, saying "Oh dear, we've lost". MS knows that and that's why they've spent $100m U.S advertising Linux, ssshhhhh! don't tell MS what they are doing, it certainly brings a smile to my face to see these adverts on linuxtoday.com and other Linux sites. Regards Sid. -- Sid Boyce .... Hamradio G3VBV and keen Flyer Linux Only Shop.
On May 3, 2004 01:13 pm, Sid Boyce wrote: ---snip out the NOW irrelevant stuff ;)---
I have come across certain documents created on later versions of Windows that can't be opened in Windows 95. You can use Microsoft or whatever you like, no one will beat you up for choosing what you like. "Linux will never ....", "Linux won't ....", "Linux can't", etc. never stopped the guys from writing the code and not caring one bit what gets written or said and I don't see them ever giving up and sitting sadly down with cans of beer in front of a TV set, saying "Oh dear, we've lost". MS knows that and that's why they've spent $100m U.S advertising Linux, ssshhhhh! don't tell MS what they are doing, it certainly brings a smile to my face to see these adverts on linuxtoday.com and other Linux sites.
Hehe, maybe they just don't have much choice - the guy(s) who came up with the campaign needed to show he(they) is/are doing something, and that was the easiest to do and explain to the bosses thing to do, besides $100m or even $1b isn't going to burn a big hole in their pockets...
Am Monday 03 May 2004 22:23 schrieb Sergei Klink:
On May 3, 2004 01:13 pm, Sid Boyce wrote:
I have come across certain documents created on later versions of Windows ...
Hehe, maybe ...
Please: MERCY !!! Spare us these convictions and guesswork ... This is [suse-amd64] !!! - Manfred.
Thank you, after export LD_ASSUME_KERNEL=2.4.21 and cp /usr/lib64/gconv/gconv-modules /usr/lib/gconv/ it works now. detlef oertel (from a desktop with linux ;-) Willibald Krenn wrote:
detlef oertel schrieb:
detlef@sepia:~> startdelphi Runtime error 234 at 56A3E9B7
I got runtime errors 234 too on SuSE 9.0 AMD64. After cp /usr/lib64/gconv/gconv-modules /usr/libgconv/ the error was gone. (Was caused due to a bug in the SuSE Linux distribution)
HTH Willi
.
måndag 03 maj 2004 17:07 skrev Willibald Krenn:
detlef oertel schrieb:
detlef@sepia:~> startdelphi Runtime error 234 at 56A3E9B7
I got runtime errors 234 too on SuSE 9.0 AMD64. After cp /usr/lib64/gconv/gconv-modules /usr/libgconv/ the error was gone. (Was caused due to a bug in the SuSE Linux distribution)
HTH Willi
Thanks a million, that did the trick.
participants (11)
-
Andi Kleen -
Andreas Jaeger -
detlef oertel -
Manfred Knick -
Marcus Meissner -
Philipp Thomas -
Sergei Klink -
Sid Boyce -
Thorsten Kukuk -
Willibald Krenn -
Örn Hansen