On Sun, May 02, 2004 at 09:46:45PM +0200, Andreas Jaeger wrote:

Marcus Meissner 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

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 writes:

...

On Sun, May 02, 2004 at 09:46:45PM +0200, Andreas Jaeger wrote:

...

Marcus Meissner 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 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

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

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

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?

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

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

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

.