On Thursday 30 January 2003 13:43, Alin Dobre wrote:

SLOVED

How?

Alin Dobre wrote:

...

hi,

i want to install proftpd and i need glibc 2.3. does anyone know a rpm for this? (suse 8.1).

regards,

-- Alin DOBRE Technical Support Engineer - RAV Division Please visit http://www.ravantivirus.com

-- Fergus Wilde Chetham's Library Long Millgate Manchester M3 1SB Tel: +44 161 834 7961 Fax: +44 161 839 5797 http://www.chethams.org.uk

Alternatively wait for 8.2 which will most probably be based on glibc 2.3/2.3.X.

What will that mean for compatibility with 8.1? Will 8.2 RPMs work on 8.1? -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"

->What will that mean for compatibility with 8.1? Will 8.2 RPMs work on 8.1?

Most likely not. But some 8.1 pkgs could very work on 8.2.

So anyone wanting to produce "current SuSE RPMs" of their product needs to make 7.3, 8.0, 8.1 and 8.2 versions? Shawn Gordon was right. This is a ridiculous situation. I have a Qt application nearing completion, and was going to release it under the GPL. Even doing "just SuSE" RPMs is looking like more trouble than it's worth. :o( -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"

->So anyone wanting to produce "current SuSE RPMs" of their product needs to ->make 7.3, 8.0, 8.1 and 8.2 versions? Shawn Gordon was right. This is a ->ridiculous situation. -> ->I have a Qt application nearing completion, and was going to release it under ->the GPL. Even doing "just SuSE" RPMs is looking like more trouble than it's ->worth. :o(

Well, Redhat 8.0 already uses Glibc 2.3. You should see the pain that alot of the RH users on the Codeweavers list went through.

Oh, I know it. Did you see the Shawn Gordon interview where he listed all the packages he has to build to support "Linux in general". He called it a nightmare and he's right. Linux on the desktop won't get too far until this nonsense is sorted out.

I see no difference in Windows packages requiring XP or 2k to run along with the fact that a lot of OSX 10.1 software won't run on 10.2 such as Safari which requires 10.2. *shrug*

I've never used XP. I've yet to buy or download anything for my W2K box which doesn't just install and work. I presume the "setup.exe" thing handles all the W2K/WinME/Win98/Win95 issues. RPM doesn't do that. Oh, and Macs don't count! The whole OS9 -> OSX thing is also a nightmare; Macs users will put up with anything! -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"

...

So anyone wanting to produce "current SuSE RPMs" of their product needs to make 7.3, 8.0, 8.1 and 8.2 versions? Shawn Gordon was right. This is a ridiculous situation.

Yes and no: As long als all libraries you need are in a compatible version on all 4 distributions, you need only one for 7.3.

My program, and currently written KDE/Qt programs, use Qt3. A stock 7.3 SuSE based machine won't run it (7.3 was Qt2 based, right?). An 8.0 will, as long as compile with GCC-2.9x, but that won't run on an 8.1. If I build for 8.1 with GCC-3.2, that's not going to run on anything older. So: I have to build a version for 7.3 with Qt2; I have to build a version for 8.0 with Qt3 and GCC-2.9x; I have to build a version for 8.1 with Qt3 and GCC-3.2; That last one should run on 8.2, but I mustn't update my build machine to 8.2 because then I can't guarantee my program will run on 8.1 because of potential glibc problems. Anyone care to explain this to Adobe when trying to persuade them to port Photoshop, et al? And of course, we're only discussing versions of SuSE, not "Linux" in general.

...

I have a Qt application nearing completion, and was going to release it under the GPL. Even doing "just SuSE" RPMs is looking like more trouble than it's worth. :o(

But you will have this problem with all Linux distributions.

Correct, it's not a SuSE specific problem. Linux in general must figure out how to maintain backwards compatibility, so as long as an application is complied on the "latest", it'll run on all previous versions. Forwards compatibility would be useful too. I have no idea how to solve this. -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"

On Saturday 01 February 2003 18:40, Anders Johansson wrote:

On Sat, 2003-02-01 at 11:28, Derek Fountain wrote:

...

Anyone care to explain this to Adobe when trying to persuade them to port Photoshop, et al?

Your problems stem largely from using c++. If your app was written in C you could even compile your app against libc5 and have it work in most environments. All distros I know of ship compatibility libs. shlibs.rpm in suse, for example.

What language did Adobe use for Photoshop?

I don't know but C++ is the defacto choice for most applications development these days. All KDE programs, as far as I know, are C++. Yes there's bindings for other languages, but who uses them? If porting apps to Linux means rewriting all the C++ ones in C, not much is going to get ported. If desktop Linux is going to be taken seriously, the problem of portability of applications between distros and versions of distros needs to be fixed. -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"

I beg to differ. C is still a huge language, gtk, motif et al use C. Objective C I think is the language of choice on Apple platforms.

Microsoft and KDE use c++, that's true.

This is straying from my point. The vast majority of the Windows applications people would like to see ported are developed with C++. There are no gtk or Motif apps on Windows, AFAIK. Asking a company to commence a port, and change the language just isn't on. Linux needs to sort out it's C++ problems before ports will happen.

It can be done. Show me the (modern) platform that can't run the Netscape binary download, for example. OpenOffice.org? Opera? I'm sure it fails somewhere but by far the most can run them as is

They carry their own libraries with them for the most part. Netscape on my box takes 38MB of diskspace, loads extremely slowly and has a massive memory footprint. Openoffice takes 192MB of diskspace. The less said about it's performance the better. I don't have Opera, but I do have Acrobat - another 25MB. You're not telling me this is the way forward are you? Ben said use statically linked apps, which is one step further towards madness. UNIX gave that up years ago. My little webcam app (I was playing with v4l) is currently a 1.5MB executable, which is bad enough. Adding Qt into the package will add nearly 8MB more. It'll soon be a KDE app, so it gets a decent file dialog, the ability to insert itself into the system tray, proper printing support, kio support etc. I'm not sure which KDE libraries will be required, but kdecore, kdeprint, kdeui and kdenetwork will all be necessary. That's another 5 or 6MB. So my 1.5MB application will take somewhere between 15 and 20MB if I try to bundle up all the libraries it requires to ship with it.

C++ is currently not included in the LSB, that's all C as far as I can see.

And that's the problem. Until it's solved I can't see Adobe, Macromedia or any of the others taking desktop Linux seriously. -- Microsoft Palladium: "Where the hell do you think YOU'RE going today?"

* Derek Fountain (derekfountain@yahoo.co.uk) [030201 02:29]: -> ->I have to build a version for 7.3 with Qt2; ->I have to build a version for 8.0 with Qt3 and GCC-2.9x; ->I have to build a version for 8.1 with Qt3 and GCC-3.2; ->That last one should run on 8.2, but I mustn't update my build machine to 8.2 ->because then I can't guarantee my program will run on 8.1 because of ->potential glibc problems. -> ->Anyone care to explain this to Adobe when trying to persuade them to port ->Photoshop, et al? -> ->And of course, we're only discussing versions of SuSE, not "Linux" in general. -> The quite simple solution is for Adobe to build their app against static libs and ship them with the program so they are housed inside the directory with the application. Or have compat libs in the system to run the software. I still use Kinkatta as my AIM client and it's a KDE2 program. It works just fine because the libs are present...even though I'm running KDE 3.1 as my desktop. I think this conversation is just a bunch of FUD and excuse for why someone can't do something. Linux doesn't have to be static for years and years to get people to port software to it. That's a bunch of crap in my book. And as of late RH, Mandrake and SuSE are pretty much on the same track together. So as long as the company making the app has some knowledge of how things work in the environment they are developing in..then it shouldn't make much of a difference. -- Ben Rosenberg ---===---===---===--- mailto:ben@whack.org Tell me what you believe.. I'll tell you what you should see.

On Sat, 2003-02-01 at 06:22, Ben Rosenberg wrote:

* Derek Fountain (derekfountain@yahoo.co.uk) [030131 21:05]: ->> Alternatively wait for 8.2 which will most probably be based on glibc ->> 2.3/2.3.X. -> ->What will that mean for compatibility with 8.1? Will 8.2 RPMs work on 8.1?

Most likely not. But some 8.1 pkgs could very work on 8.2.

I would say most likely. I'm currently running glibc 2.3.1, and I'm quite able to run apps built on glibc 2.2.5 machines -- Anders Johansson

On Sat, Feb 01, Derek Fountain wrote:

...

Alternatively wait for 8.2 which will most probably be based on glibc 2.3/2.3.X.

What will that mean for compatibility with 8.1? Will 8.2 RPMs work on 8.1?

As always: programs linked against a newer library version must not work with an older library version. This is true for every Operating system, even Windows. You can have luck and the glibc 2.3.X compiled binaries will work with glibc 2.2.x, but there is no gurantee. But glibc 2.2.x binaries will continue to work with glibc 2.3.X, as long as they don't call forbidden, internal glibc functions. Static binaries are different: If you have a real static binary, which does not use NSS: It will continue to work. If you have a pseudo static binary like RPM, which will dlopen NSS modules and glibc: No, they will not work anymore, you have to recompile them. But this binaries are outside of the defined interface. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Deutschherrnstr. 15-19 D-90429 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B