Slashdot Mirror
Linux Applications And "glibc Hell"?
cybrthng asks: "How do you stop glibc hell on Linux? I thought I'd long lost the ever familiar DLL hell on Windows, but with Linux it breaks the applications so bad its not funny. Will Linux only be able to truely survive with applications available in source form? For instance take Oracle Applications, it is nearly impossible to install it on RedHat 7.0 or any glibc 2.2 based distro since the applications were built against 2.1.x. When you install this software it tries to relink itself with the correct libraries and fails miserably. You can however force it to use glibc-compat, but that isn't a solution for a production system. Do vendors have to recompile there applications for every kernel, every library and every distro? How can I use Linux when the core libraries don't seem to be forwards or backwards compatible across different distributions?"
For my company glibc is at the heart of most of our linux porting issues.
To make it worse the glibc versioning is next to useless, take linuxthreads for example, a rewrite was called libpthread 0.8, the previous version was also called 0.8 what is a vendor to do, start telling customers to run sum on all their libraries.
This backfires for linux as companies are less reluctant to keep up with distribution updates.
Moving to the latest release is already a pain for us, we have had 4 redhat revs in the time that we had NT 4.0 and Win 2000. That means extra development machines, build machines and test machines...
There's already been much talking about redhat 7.0 incompatible glibc. But it's the only distribution which ever chose to ship with a beta of glibc that is not compatible with previous versions.
Use Debian instead. see debian.org
The previous poster was correct in saying that Win95/98/Me and WinNT/2000 are separate code bases that share not only the same APIs (e.g. Win32), but also have fairly close to 100% compatible ABIs. Only the very few Win32 applications that grossly deviate from the Win32 programming guidelines have compatibility issues (excepting drivers, of course, which are totally non-compatible). I can't comment on your experience, but in my experience (and most other people's) there aren't any compatibility issues between the Windows platforms as long as you read and follow Microsoft's guidelines.
The point remains. If Microsoft can do such a good job of maintaining a stable ABI across two separate code bases, why is it that we have so much trouble with a single code base? In the past few years, we've gone through libc5, libc6.0, libc6.1, and libc6.2. You would think that something like the C API and ABI would have been stable a long time ago, but even 6.2 breaks some code compiled against 6.1. Don't even get me started about libstdc++. The open source implementation is *way* behind what you can get from SGI, Sun, KAI, etc.
Wtf are you talking about? I installed oracle just fine on my glibc 2.2.1 box here. Running debian testing/unstable.
See subject.
For instance, several of the codecs for xanim are distributed only as unlinked object files.
Actually, hard drive space is THAT cheap.
10G drives are below $100 now.
A Pirate and a Puritan look the same on a balance sheet.
Ok then: What are the relevant bugs that an Oracle DBA running on Redhat 6.2 would have to deal with?
A Pirate and a Puritan look the same on a balance sheet.
No. Something as big as Oracle would likely be the one service to determine what the standard for all the others is. This isn't XBill we're discussing here.
A Pirate and a Puritan look the same on a balance sheet.
They aren't 'that' different.
Solaris and Linux aren't advertised as being binary compatible with each other.
Win9x and WinNT are. You don't see seperate shrinkwrap for the two.
A Pirate and a Puritan look the same on a balance sheet.
You have two options to deal with Linux here: provide gigantic static-linked binaries, which will cripple the freedom of your users and make their systems inefficient, or provide source code they can compile on their platforms (this way enabling your application to run also on other architectures like PPC, Alpha, Sparc...).
Yet, if you are willing to cripple user freedom, then just make binaries for a reference distribution (Distribution ZZZ version X.Y) and put a neon-orange sign in the shrink-wrap box "Requires ZZZ Linux X.Y". You're already taking the users' freedom in respect to the software they use, taking a little more and obligating them to use an specific version of a distro is just a step further).
If you are not willing to provide the source code for the users of your software, you'd better not be developing software, the world is better without you. Really.
This isnt a open/closed source issue. This is a issue of compatabilitiy and regression, which, believe it or not, transcends open/closed source issues in alot of cases. It doenst take a glibc coder to realize that. Responding with "Well it serves them right because they're not open-source, nyeh!" is a cop-out and trite. Look at the big picture, because it's not only closed-source products that can run into this same problem.
Let's say that Oracle releases it's database which is statically linked against glibc 2.1.3. A few days/weeks/months later, a security/performance bug was found, perhaps even in a function that the staticly-linked Oracle binary uses... a bug severe enough to warrant everyone with 2.1.3 systems to consider upgrading ASAP. As I'm sure you're aware, under a dynamic environment, all one would need to do is upgrade the glibc so's to 2.1.4, reboot, and be done. All programs that were affected by the bug in 2.1.3 now link against 2.1.4 when they start and all is well.
Except for our Oracle binary. It is then up to Oracle to re-release their product, but built against glibc 2.1.4 now... incresing the amount of time the problem hangs around, increasing downtime for the user (instead of rebooting once, they now need to shut down Oracle again to upgrade), and basically keeping a release hell for vendor and user.
Glibc 2.0 is NOT glibc 2.1 which is NOT glibc 2.2. The glibc guys fucked up, this is true. I would have called these libraries something different (glibc2/3/4?) This is easy to fix though: I can install all three of these libraries and the softare can link up with whatever lib it wants. You can't do that (properly) under the Win* systems. I wouldn't call this DLL hell at all. A nuisance, yes. A potential security risk (having old libs with old holes), yes but I think that can be worked out (proper perms?) The point is this is a rather simple problem, and certainly workable if need be.
My next point is that you are really bitching without reason. When an app asks for glibc2.1, bloody well give it glibc2.1. If you either can't or won't, don't bitch at the software. Are you also the kind of person who demands his car be fixed and then insists on putting Toyota parts into a Honda?
Me, if it can't come from `apt-get -b source foo' then it doesn't get installed.
Exactly why I dislike package tools of any kind.
Why should I wait for debian (or software writer X) to come out with packages? Grab the source tarball and install it. Hell there are even a couple of really nice "install" replacements which log what got put where and at what time for nice and easy removal.
Requiring everything to be an RPM in order to keep the RPM database happy is what turned me off of RedHat (well that and the idiotic system config structure). The exact same thing keeps me off of Debian and its derivatives. Package management must be as low-level as possible or it is useless.
"Another thing: BeOS uses the egcs compiler, and they somehow managed to have very high binary compatibility even with _object oriented_ libraries. For example, they add dummy virtual functions to classes so that the layout of the virtual method table does not change when they add new functions. Linux developers should take a look at this. "
That sounds an awful like one of the original design concepts behind COM.
"How do you stop glibc hell on Linux? I thought I'd long lost the ever familiar DLL hell on Windows, but with Linux it breaks the applications so bad its not funny."
.dll files have no version associated with them. so if app x requires foo.dll version 1.2 and app y requires foo.dll version 1.5, they will both try to install their own foo.dll and break the other app. that is what .dll hell is.
this is actually quite simple to fix. you see, dll hell in windows refers to the fact that the
this "glibc hell" that you are referring to is of your own creation. you are trying to run a program that is linked against (for example) libc-2.1.3.so with your library libc-2.2.0.so. the problem is not that libc-2.1.3.so and libc-2.2.0.so are incompatible. the problem is that you are attempting to run a program that is linked against libc-2.1.3.so and you don't have libc-2.1.3.so installed. that's the problem. install libc-2.1.3.so, and your problem will go away.
this is true like 99% of the time. if your application vendor had any sense when they compiled the program, which they better if they dont want to make source available, then they will link against the appropriate versions of the library. and if you have that library for it to run against, then you can run it, even if the primary libc on your system is a different version.
the one case i've found to truly be a problem is if you have something linked against one version of a library that dynamically loads something linked against another version of a library. i had a problem once with trying to get the realplayer (i think) plugin working with a version of netscape that was compiled against a different libc. but in a case like that im not sure if there really is a good solution....
If I don't put anything here, will anyone recognize me anymore?
Build against libc 5 and you eliminate all compatibility problems. I do it and it works great.
I agree totally, this happens with Windows OSes too. When was the last time you didn't see a big application require SP3 at least on NT4?
This is true for every operating system out there. You can try and force it to install with a bunch of hacks etc on an "unsupported" system, but really why? What does RH7 give you on an Oracle box that RH6.2 can't besides less stability and incompatibility problems.
-jay
--
Fuck the system? Nah, you might catch something.
How can I use Linux when the core libraries don't seem to be forwards or backwards compatible across different distributions?
All this philosphical debate is nice but could someone answer the question that was asked?
I believe they want to know how to install multiple glibc libraries and get them all to operate with whatever software needs them. In Redhat and Slackware I know there are packages(rpm and tar.gz) for each of the libraries so I assume that should be easy enough, just grab the package for the glibc version and install. But what about other distributions, and how about some detail? I'd be interested to know myself.
And how the heck are these comments getting scored as Insightful and Informative when they don't answer the question or even try!
This is exactly the same sort of problem Windows developers have when they wish to switch from e.g. VC++ 5.0 to VC++ 6.0 but they have a third-party library (such as Oracle stuff) that was built for the older of the two.
In neither case do these problems affect end-users.
...whatever happened to the days when the std in stdlib actually stood for standard? I wonder what it stands for now...
I ran into this oracle install problem on my Debian Sid/ kernel 2.4 system..t xt
Here is a description: http://www.fortyoz.org/files/misc/oracle_trouble.
Anyone have bright ideas? I'm thinking about install redhat 6 on a spare drive, installing it then copying it over..
Sigh, all this just for the client libraries and headers.
Remember that static linking glibc into a commercial application violates the LGPL. The LGPL only allows dynamic linking without forcing you into LGPL/GPL.
um, I'm not sure Redhat 6.2 will be falling off the face of the earth anytime soon.
Redhat 4.2 and 5.2 were both supported for years. And considering how bad 7.0 is, I wouldn't think you'd have to worry about 6.2 going unsupported for at least another two years. Hell, they're still supporting 6.0, and that came out close to two years ago.
There should be binary compatibility of apps over a long period of time. MS only gets away with breaking this every couple of years. This means,
for these are the things that break binary compatibility. And yet, all these things are done without thought to the consequences.
Start Running Better Polls
Yeah, yeah... I realize this is back in the day and all that but still...
Why is an application attempting to link against glibc-2.1.x? Why is it not linking against libc.so.6? If it did this then, as long as your glibc is not earlier than the one against which the application was built then versioning within the library should take care of everything for you.
Upgrading from glibc 2.1 to 2.2 should not require upgrading anything else. The upgrade from glibc 2.0 to 2.1 required rebuilding a few things - such as ncurses and gcc - but not many.
Ooops. I forgot one incompatibility. It is not possible to build gcc 2.95.2 using glibc 2.2, without applying a patch, as there was an incompatible header file change. However the gcc 2.95.2 built using glibc 2.1 will still run perfectly well under glibc 2.2.
I too have gotten exasperated by this issue. I'm not a developer, nor do I want to be one. I'm not a unix sysadmin by profession either (wouldn't mind learning, but it's not a priority). Windows DLL hell was nothing compared to the problems with dealing with libraries under Linux. I've actually found it easier to "upgrade" the distro to a newer version than update libraries. Granted, once it was working, it never broke, but it was a pain to get there. After nearly 4 years of use, I switched to W2K. It's not perfect, but it lets me do the things I want to do today.
Chris
Ensure that symbol versioning is built into your glibc (which it is by default - it has to be actively disabled if you do not want it). Then any programs you link against it will use symbol versioning, and any binaries you run will automatically pull in the correct version from the runtime library.
It's not just non-free apps that have a problem. I am running RedHat 6.1, and I can't install any KDE RPMs because they all require glibc-2.2, and I don't want to upgrade glibc, because a) all my current RPMs require glibc-2.1, and b) it's stupid to have to upgrade every app on my machine for one new app. Sometimes I can fool RPM by linking foo.so.1 to foo.so and so forth, but that's really stupid. So instead, I have to compile things from source, which in the case of KDE, took me about 3 full days.
Gee, that sounds like what Microsoft does for its Win32 C library DLLs. Not dissing you, I'm just amused at how the Linux community ends up reinventing Windows time and time again.
One of the problems with using a static C library is that it has global state, and sometimes various shared libraries written in C will need to cooperate -- in those cases, the shared state has to be managed by shared code. If the code is not shared at some level, the state won't be shared.
What you say is certainly true for enterprise-ware like Oracle, but that doesn't mean that binary compatibility isn't a real issue! The quantity of binary-only distributed Linux software grows daily, but the prospect of providing and supporting versions for even 80% of the installed Linux architectures and kernel and library versions must surely be dissuading manufacturers from porting?
Assuming that the Linux community wants to support closed-source software, surely some solution has to be found to at least ensure that such software works on the majority of the major distributions and versions?
Oracle may be a poor example, but the problem is real.
Actually, I really would like to write a Python-based OS.
The only problem is I have this day job... I could get by without money, new clothes or a car, but not an Internet connection!
This is not strictly true. Most applications are well-written enough to work across glibc versions. Most glibc versions are written (or rather, unpatched enoughed, depending on distro) well enough that most applications will not break when glibc is upgraded. One glaring exception is StarOffice--if you'll recall, at one time StarOffice was using private internals of the c library. That's was bad coding on SO's part--not compatibility-breaking by glibc. Another example I can think of (please someone tell me if you've fixed this) is IBM's JDK 1.3--it doesn't work with glibc 2.1.94, as far as I can tell. Sun's JDK, however, works great still.
The point is, I can write an application, for profit, closed source, and distribute it in binary-only form, and have a sure expectation that it will work on a majority of glibc-based systems. That's making the very reasonable assumption that I write my code in such a way that it is NOT relying on private internals of the library, or on known bugs in the library.
Someone else made a suggestion that glibc should be a skeleton, and the internals stored elsewhere. I submit that that is already the type of model glibc follows. Even were glibc to store it's body somewhere else, and present only the skeleton, someone, somewhere, would figure out how to call functions in the hidden body--and that someone would complain very loud and long about the body changing. Even though that someone KNOWS that the body functions are off-limits and subject to change without notice.
Write and link your application and pay attention to the very few caveats revealed by the GNU glibc team, and your app will run well on many different versions of glibc. Ignore the prophecies of the GNU glibc team, and you may be assured that your app will go down in flames.
Matthew Vanecek For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting i
sxpert wrote that "applications that rely on bugs should die and be forgotten".
Should Linux die and be forgotten?
Je ne parle pas francais.
Then these (badly written) applications that rely on bugs should die and be forgotten
Didn't earlier version of the Linux kernel (I think pre-2.2) rely on bugs in GCC to compile?
One of the reasons you can't take the latest GCC and compile pre-2.2 with.
Je ne parle pas francais.
These problems with virtual methods that Be so diligently works around are totally gone if you use a sane object-oriented language, like Objective-C or, better yet, a non-C-based one. Sure, with enough time and effort you could probably mold that hammer into a passable screwdriver, but why not just start out with a screwdriver in the first place? I think Be's work with C++ should be looked at as a massive, stupid effort in using the wrong tool for the job, rather than some amazing achievement to be commended.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
gcc 3.0 (in some kind of feature freeze at the moment) implements a (promised) stable C++ ABI.
Also, that ABI is cross-vendor so I presume that this means you'll be able to link with C++ libraries compiled with other compilers.
btw, microsoft broke binary compatibility in some of their core libraries (i think it was msvcrt.dll) when they released VC++ 6. I was outraged at the time, and it made things very awkward but, for instance, the Red Hat 7 situation is incomparably worse.
stay frosty and alert
In theory, glibc already transparently supports this mechanism via something called versioned symbols. Versioned symbols basically let the linker say (when the executable is built) 'this requires not just strcpy(), but a GLibc 2.0 compatable strcpy()'. (You can see this relatively vividly by running 'nm' on a shared library like libdb; versioned symbols will have names like 'unlink@@GLIBC_2.0'.
The theory is that when the GLibc people change the interface for something they provide both the old routine and the new one with different version names; one will be 'unlink@@GLIBC_2.0' and the other will be 'unlink@@GLIBC_2.1' or the like. When an application is newly linked, it presumably normally links to the highest version; however, when an old binary is run it gets the old 'unlink@@GLIBC_2.0' that it expects.
This fails if either the GLibc people don't realize that an interface has changed, or the routine (or the interface detail) is one they consider an 'internal' one, subject to change without notice and backwards compatability because no user program is supposed to be using it (or depending on the routine's undocumented behavior staying the same). And of course they have to get the compatability code right. This also only works for executables already fully linked; if you relink from object files et al, you normally get the highest version of the symbol defined, even if you don't necessarily want that. (It appears that there is no way to control this behavior in ld, unfortunately.)
i experience the same hell everytime i want to try out a new application. somehow i always need to download 300 MB of dependencies before i can build the app i want to try. why can't developers just stick to the libs that are present in the latest distribs? this is _The_ problem that keeps keeping me away from running linux for all my needs...
Even so, is that a big deal? Binary-only software on Linux is the exception, not the rule. So maybe you have a few programs that are statically linked, but it's not like everything (e.g. ls, grep, XFree86, etc) is linked that way. It's like your whole system is going to start thrashing; it's a small incremental performance downgrade.
Also, it occurs to me (I could be quite mistaken) that the people who are running binary-only static-linked programs, are going to have a high spec machine anyway. If you're running Oracle, you're going to get a database box that kicks butt. If you're running Loki games, your gaming box is going to have a lot of RAM. The guy with the 486 and 16 MB isn't likely to run the kinds of things that he can't link for himself.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I think someone's pointed this out, but it bears repeating: if an application needs glibc 2.1, then install glibc 2.1. Don't downgrade 2.2, just install 2.1 alongside it. No headers or anything, just the libraries. Then the apps that need 2.1 should find it, and the apps that need 2.2 will find it. If needed, you can set LD_LIBRARY_PATH and LD_PRELOAD to force loading of correct versions. Unlike Windows, Linux allows multiple versions of a library to be installed without stepping on each other.
Oracle 8i does work on Slackware. But its installation routine relies on specific paths for some system utilities that only apply to Red Hat and its derrivatives. I have successfully installed 8i on Slackware by following the advice here.
Strange - I put 'upgrading glibc' into Google and turned up loads of information. Could the parent post be 'Flamebait' ?
Most of it said upgrade your entire system to be compatible with the new library, but others also said that glibc2.2 was backwards compatible with 2.1.
From your last post I guess the language in your requests just p**ses people off!
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
As I remember glibc is a rewrite.. the original libary was libc...
It would be painful but I think we could in fact rewrite libc again...
I don't actually exist.
You mean it Eventually Mallocs All Core Space?
:-)
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
If you don't believe me, try downloading my Netrek client Paradise-2000 and running the static glibc2.1 binary on a system with an older libc. Hostname lookups won't work. The problem is that glibc2.1's resolve code tries to access the dynamic library /lib/libnss_files.so.2, which doesn't exist on
pre-glibc2.1 systems. Since this library isn't dynamically linked, it doesn't
show up in the output of ldd, you can't statically link it when you compile
the program. Rather, the /lib/libnss_* libraries are loaded with dlopen().
So I'm forced to compile three separate static versions of my program, and that doesn't even count glibc2.2 which I'm not using yet.
Another problem with static linking is one of efficiency. A statically linked program has it's own copy of the libc (huge) in the executable. Besides making the executable huge if you want to download it, it uses a ton of extra memory. Instead of using the copy of libc that is probably already in memory and shared with the processes you have running, the statically linked program needs to load its own private copy of the libc code into memory, which won't get shared with any other program. The result is the memory needs of your system would double or more if every binary you had was statically linked.
I have had to repair drivers/applications written by people with the best of intentions (but no clue) but I thanked them profusely for their contribution when sending them a patch.
Can you help the glibc effort, other wise -- be constructive.
I understand the desperation in your voice, I feel it everyday, but I also thank god that I am not a MicroSoft slave anymore -- freedom has a high price.
By installating a suite of development tools on a production system, you're providing that many more potential security holes to the would-be cracker.
In addition, since most recent applications use dozens of APIs on top of the standard libraries and the Posix API, you're looking at potentially installing hundreds of megabytes of headers, debug libraries, compiler binaries, preprocessors and other development tools, on every single system you own. This is a phenomenal waste of resources, both disk space and time.
If you want portable code, then you should write everything in Java (or Python or any other language which provides for cross-platform binaries and supplies a rich set of universal APIs.)
If you aren't willing to do this, then you must be willing to live with the fact that computers are diverse, and varied.
Certainly, for single users it makes sense to compile your own binaries. You get to choose your optimizations, configure the programs to suit your needs, install everything just where you want--and most important, you gain experience which makes you a better power user and eventually leads you down the road to coding!
It's just not a viable solution for people who need to administer more than one machine, or who lack the time, tenacity or willingness to delve into the mysteries of the tools they use daily.
It's still not a good idea from a security standpoint, but this is not a problem if you're just doing this on your personal system at home.
Lately I've taken a clean-room approach to all my app packaging. I install Linux into a VMWare session running the exact distro and version of the OS I'm packaging software for; I install *only* the tools that are available on the target platform, plus exactly what I need to compile the software. It's been working very well.
The problem is when you decide to loop over all vertices in the polygon to compute the surface normals.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
If you're building/packaging programs then following the guidelines in the LDPS will help maximise the portability of the binaries.
To state the problem briefly:
A type describes the properties and operations that make sense for a given value, while a class describes the implementation details of the value.
There is no necessary connection between the two. However, since C++ horribly confused them, most programmers don't know the difference.
That's "Mr. Soulless Automaton" to you, Bub.
Yup. A Java "interface" purely defines a type. A Java "class" defines both a class and a type.
That's "Mr. Soulless Automaton" to you, Bub.
Although I'm not currently running Linux, I've encountered similar situations over the last couple of years.
When GNOME and KDE were fairly new, I had to install dozens of packages to get them working. But then I wound up with several different versions of libraries on my system, because each piece of software wanted "this-week's" libc or libgtk.
The situtation was complicated by the conflict between RPM and source distributions. I would download, compile and install something which provided a certain library, but because that came from source and not an RPM, another package would not know it was available, and would insist I install it again in binary.
While up-to-date resources are convenient, I do not own computers for the purpose of slavishly obeying package developers' requirements, or to provide archive space for the five most recent versions of a library.
TomDLux
A project i was working on at work needed to make calls (through Corba) to this big hairy fangs and claws having library from a third party that was written in Java. Now the neat thing, is that they didn't use any of that vendor-specific crap, so they actually shipped the same library for NT, Linux, Slowlaris, Tru64, and whatever else...
It was actually pretty impressive, and it worked too =:-)
Now that being said, i sure as hell wouldn't want my standard libraries to be in Java, 'cause it'd be slow as hell.
---
Play Six Pack Man. I
Ive always wondered that. How does one force linking against libc.so.6 insteadof glibc-2.x.x? Thanks
This is a dumb comment; what kind of applications are you talking about? Huge database apps like Oracle or DB2? Then, the cost of the hardware is gonna be negligible compared to software licencing costs, so yes, two machines for two applications, it their requirements are incompatible.
Yeesh people, do some homework or something.
-elf
If the differences are too great, you can always extract the correct version of the libraries from an old distro and store them in a handy directory. Then, point the program to the directory using the LD_LIBRARY_PATH environment variable in a shell script wrapper. A number of packages use this method.
--
"You've crossed my Line of Death!" "What? No! Where is it?" "Here in the fine print...."
We avoid the whole issue by only distributing binaries that are statically linked. It makes for bigger binaries, but I'd rather have a bigger binary, rather than one that won't run.
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
Notice I said Thousands of DLLs. If what you said was true only system administrators could install software because every single windows app drops at least one DLL into the WINNT hierarcy.
War is necrophilia.
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
What you need is an open-source Unix that treats the kernel, libs and "user-land" stuff as a whole, not as a mishmash that varies for each "distribution." In other words, you need Free/Net/OpenBSD :) There is no such thing as a "version of Linux" per se. Linux is just a kernel which, as you've discovered, can be distributed with an annoying variety of core libs and user-land applications.
Sorry if this sounds like trolling, but I consider this issue one of the biggest thorns in the side of Linux, and one of BSD's greatest advantages...
Funny- when I read the original posting I assumed the "notable exception" referred to was Emacs, OF COURSE.
--
keete
perl -e 'fork||print for split//,"hahahaha"'
... that this is almost a non-issue.
Have a look at this page (written back in July 98), which compares libc with glibc.
In particular:
"Programs compiled to use libc 5 will not run with glibc, and vice versa. However, glibc includes support for "symbol versioning". This will virtually eliminate the need for another incompatible libc switchover, like the one from libc 5 to glibc, to ever happen again."
In other words, you can have multiple versions of libc installed alongside each other and applications that use either will work. I have libc2.1 and 2.2 applications both running right now on my mandrake linux desktop.
(Am I missing something here?)
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
You aren't in glibc hell, you're in Oracle hell.
Oracle has too many problems to list here, but of particular interest to you is its extremely finnicky system requirements. It's the least portable, worst installing POC software I have ever seen.
Even in its own world, Oracle is neither backward nor forward compatible.
glibc is a legitimate weakness/complaint of linux - in fact, even the whole notion of shared libraries is - but you lost me the second you mentioned Oracle.
> btw, don't bother looking for signatures in GNU C++ anymore--they got sacrificed on the altar of strict ANSI C++ compliance, like so many other good GNU C++ features.
Can you list what other nice features GNU C++ had, that got pruned? (wasn't #pragma pack(n) another one?)
What was the first version of g++ that had the signatures removed?
Thx !
So basicaly, what you are calling "type" is the "interface" to the object?
> Also, the fact that languages like C++ and Java tie inheritance hierarchies to static type checking is an unnecessary and idiosyncratic restriction.
Can you provide some examples of what you mean?
And can you provide some examples of a language that doesn't do this?
Thx
and in bad need of a cleanup. The Makefiles are utterly incomprehensible for a start.
I remember my second professional foray into using UNIX, about 9 years ago. My group was given a book on UNIX System V to help us familiarize ourselves with the system. The book had a lot of general background/historical info on UNIX.
One thing that I vividly remember was that, for any UNIX distribution to claim that it was compatible with (something or other), it had to faithfully reproduce 99.9% (or some similar proportion, I know it was > 99%) of all the BUGS in some particular Bell Labs release from quite a few years earlier.
Now, ** THAT ** is compatibility.
I didn't say it wasn't dumb. I just said it was a powerful enforcement of compatibility standards.
Part of the reason it made such an impression on me was that I realized that it prevented both correction and innovation, so strong was the commitment to absolute compatibility.
280MB is huge. A full install of applixware 5 is about 380..but that comes with dictionaries in a lot of languages, a few thousand pages of docs(including the entire ELF user and programmers guides, the words file format reference, all of the user manuals, and lots of sample docs). If I killed the words tech references, the extra dicts, applix realtime, some of the docs(the alternate language ones). Boom, my install is trimmed to about 200MB for a lot more than word gives you(try a nice ass development enviroment that you can code both macros and programs in, an actual dictionary with word meanings, etc). And, it uses way less memory / lacks the annoying clip. Yeah, I can't right click for spelling corrections, but here is a little known secret:
position your cursor in the misspelled word and hit F3
Guess what that does? It pops up a list of corrections. And you don't even have to use the mouse, just select the correction with the keyboard and hit enter. A bit hidden, but it is there.
-------------
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
This is too true. For some time SP5 for NT broke Lotus Notes servers. On HP-UX Oracle more or less requires you to change your kernel settings and recompile.
This used to be the way to install drivers on SunOS (and later Solaris). This was before
.o) and use insmod, rmmod
dynamically loadable drivers.
You added your entries to cdevsw (or something like that). Recompiled the driver table and
and re-linked the kernel.
Later on, you could build a dynamically loadable module (still a
just like Linux today.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
"The workings of the new UI rely on a side-by-side sharing requirements structure. As a solution for versioning problems and DLL Hell, Microsoft strongly suggests that applications adopt a side-by-side versioning strategy. As seen in the implementation of ComCtl version 6, side-by-side components are the future of Windows development. This section gives you an overview about what's new for side-by-side sharing for Windows XP. MSDN will be publishing an article in March 2001 that looks into this topic in more depth." From http://msdn.microsoft.com/library/default.asp?URL= /library/techart/winxpintro.htm
I think his key point was that he might have been able to move the company from Windows to Linux if Linux didn't have a "glibc hell" problem. In other words, Linux lost a potential migration for completely stupid reasons.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
price wise, not space wise.
I run linux on a laptop. nuff said
--- I hate my sig
Don't blame "glibc hell".
Blame that *&%( RedHat for shipping libc.so binaries that are incompatible with everything else.
remember that bloat that everyone gives windows, and commercial software in general, a hard time for? this is why it's bloated, because they always have to maintain backwards compatibility.
personally *i* like the fact that linux is a hacker os. i like that it's extended to those of us that aren't guru programmers, but i don't think it's bad that linux is dynamic and changing. that is what has allowed it to catch up with commercial offerings. if you want to force backwards compatibility then you are going to cause bloat and and the slow down of innovation.
imho this is where distributions like caldera have the chance to shine, and they are what vendors should be porting large commercial aps to. caldera provides businesses a more traditionally stable unix for vendors to port to and for business users to use.
don't force commercial standards on the linux developers, that is the job of the distributions that choose that path. now if only there was a distro like caldera that was based on debian ...
Don't you remember the /. article a few months ago where M$ claimed to have "invented" a new way to solve their "DLL hell" by "inventing" a way to replace copies of the same file with a link to just one file ;)
Anyway, this whole discussion is stupid.
Unix's shared object versioning has always made "DLL hell" not applicable to Unix.
If you're making a logical link to a different version of the library, then you risk the stability of the application (but I do it too).
Shared object versioning allows multiple versions of the same library to all exist in the same directory, and the app to be able to specify which version it was compiled and tested with.
The only problem here is that Oracle didn't include the shared libraries in their app's distribution, in case the needed shared libraries didn't exist in the users system.
No WinDoh's app vendor would be stupid enough not to include all the necessary DLL's, and overwrite them upon app installation, breaking every other program but theirs!
When I die, please cast my ashes upon Bill Gates -- for once, make him clean up after me!
You can simply install the correct glibc or why just not ask to Oracle to give they source code. Then you could build your own oracle system to suit your need.
Compiling yourself isn't without its problems, either. Often you find yourself trying to compile a source (which *should* work on your distro, gcc version and so on) and it won't work. 'Course, with a little C++ knowledge, you can often fix the problem, but you shouldn't have to be a programmer to get Linux programs to work.
Can you hear me, Major Tom? I'm not the man they think I am at home...
Boy - someone's got a problem with brainstorming, eh?
No, you're right. The idea would be that they wouldn't have to. It could be along the lines of "there is a potential software upgrade - would you like to try it?" with a button for "details". My thought was that, although these kind of library updates could be done silently, it would be a good idea to be able to refuse for those times when the user does know that they don't want to.
A seperate user-initiated toolset for testing these things would also solve the problem.
I doubt any of this will happen, but I think it's worth thinking about.
Would those guys be willing to help in the effort to mainatain such a library? I wonder.
..and why i far prefer freebsd. 1 distro. one glibc, fewer fools.
In that case, just go out and buy a 20GB IDE hard drive for $99.
20 GB ATA hard drives for laptop computers cost much more than $99. A laptop is all many students at my school have, as they are issued one at the start of their freshman year.
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
Almost any consumable quantity whose extent is limited has or will be referred to at some point as a "resource".
Resources under GNU/Linux (and other POSIX) systems are called things such as "memory," "free space in /var/tmp," "processes," "LWPs," "texture memory," etc. But when a resource is actually called "System Resources", and it's measured in percent, ten bucks says it refers to the 64 KB USER and GDI heaps in Win32, which can't be enlarged without breaking Win16 apps. (See also Resource Meter.) I see no analog to the 64 KB USER and GDI heaps on POSIX+X11 systems.
And to the OP: A program CANNOT use 125% or 250% of system resources, as your kernel won't let it.
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
When you use emacs that way, it only requires 125% of system resources, rather thant 250%.
Only Win32 systems actually have a resource called "system resources," which is (in Windows 9x's case) a pair of 64 KB heaps (one for user interaction, one for graphics structures). A running NTEmacs instance takes less than 2% of each heap.
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
Hell because it fails to link because it's not compiled for it?
I won't call this hell.
Hell, like the DLL problems on Windows that where
cited, is when it can be linked but crashes on
execution due to incompabilities.
What we have since the ELF format is security against these crashes.
The problem that Linux Distributions are so different is another. But that's not glibc's fault.
Don't believe MS about multiple dll's for w2k. If you put the version of the dll that you need in the directory with the executable, the program will use that dll, not the one in the system directory. The only real change is that in 9x, if the dll is already loaded from any location, that version stays in memory and is used.
I get chips designed, and fooling with Linux isn't stopping that, or even slowing it down. This is adding a little extra, on my own. Besides, I have usually had some tool responsibilities, as well.
I see the future heading toward commodity PC hardware. With no preventive action now, corporate suits try to move things toward Windows. My job now is done on Unix, so I see some attempts at Linux migration as preventive precaution.
The living have better things to do than to continue hating the dead.
Keep in mind RedHat 7.0 is compiled with a non release version of gcc - one that is likely to be incompatible with the next release of gcc. Personally, I think the binary incompatibility hell has just started for RH 7.0 and that RH 7.0 binaries could very well be incompatible with RH 7.1 I think it is fine that RH has released such a bleeding edge product but I think Oracle would be probably doing the right thing is saying "our stuff runs on RH 6.2 but we are not going to support in on 7.0 until it is less bleeding edge. Like actually had the 2.4 kernel and is compiled with a compiler that is at least a beta release of the compiler. The important point for the average Linux user is, open source does involve getting new stuff out early (thanks RH for doing this) but the flip side of this coin is that just because it is newer does not mean it is better. If it does not do what you want to do, it is is not better and perhaps you should use something else (like RH 6.2)
applications that relies on bugs in the library in order to work, may break when new the library is updated.
Then these (badly written) applications that rely on bugs should die and be forgotten
OF COURSE, I did too, until he started ranting cluelessly about glibc :-)
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Admittedly, things were worse in the past. You don't give a lot of details in your post, but remeber, if you're talking about libc 5 (which is only remotely related to an old version of glibc), or a linuxthreads add-on that was not blessed by the glibc developers, then it's not fair to blame glibc.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Someone suggested to use static linking for compatibility, but is this allowed if the application is closed-source? I seem to remember that the LGPL is picky about only allowing dynamic linking.
Send in the lawyers.
Laid-back languages allow programmers to make mistakes they wouldn't otherwise, but it also provides an ease-of-use sorely missing from C.
For instance:
Java: at runtime you cast an Object to a circle. A catchable exception results before you can do anything dangerous.
C/C++: at runtime you cast a void* to a circle*. nothing happens. you write to a field in the circle and... buh. Potential memory overwrite.
I've recently been writing a bit of c whereas for the past 3 years it's been totally Java. Now I find in practice that exactly the opposite of what you say is true.
If something compiles in Java it means it's pretty solid. I thuroughly abuse the compiler output by just typing and then solve the compile time errors one by one rather than spending a lot of time thinking about types and such(to an extent).
But if something compiles in c it means exactly nothing. It's much more likely that you reference a pointer that points somewhere you didn't expect than accedentally put a circle object into something that's supposed to take polygon objects. What's the difference between this and a linked list data structure in c that takes void *?
I got Oracle 8i running on slackware just peachy. The worst part was the actual installation phase. Once it was installed, everything worked just fine. I resolved the installation issues as I encountered them by keeping well read on Oracle installation procedures for Linux. The worst issue I encountered was the fact that certain binaries are found in /usr/bin in slackware and /bin in redhat or vice versa, and the installation program seemed to expect them in the redhat location. This coupled with the fact that the installation program gave little clue as to the actual cause of the installation failure caused me several hours of grief. Nevertheless, I had Oracle 8i up and running in a single day (what a fun way to spend Christmas, huh?)
File under 'M' for 'Manic ranting'
-
/lib/libncurses.so.5 /lib/libncurses.so.4
Not much, but it works for me:
ln -s
(That's an example, and it really runs here.)
This is exactly right. A system designer looking to implement oracle on linux will research the requirements to be sure that the setup will work properly when everything is installed. I can't imagine that Oracle really cares about Joe Blow trying to run their software on the latest & greatest distro. They care more about the professional systems engineers, who are more likely to be using older, more stable/more well known stuff.
-bluebomber
The Daily Build
Microsoft's specifications for the DirectX libraries contain, as you might expect from a library spec, definitions, descriptions and examples for a bunch of functions. It also specifies the in-house rules Microsoft uses to update DirectX - specifically, once a function is put into DirectX, it is never removed and never updated. Each subsequent release of DirectX contains precicely the same functionality of previous releases in addition to new functionality. Functions can be "obsoleted", but are never removed or disabled.
Obviously, this makes DirectX kind of bloated, but at least you know that installing a new version isn't likly to break your old stuff. When sorting throught DirectX functions, they tend to be grouped by revision (oldest.older.old.new.newer.newest). Older applications that aren't aware of the SuperWizBang(int a) function from the latest release can just continue using the function it replaced.
As I said, it's not the best solution, but it's simple and it works. If it makes you feel better, I'm sure you can find an example of this kind of specification from someone other than Microsoft.
--
In spite of the suggestions and all the tests that I have made, I have not cavato a spider from the hole.
Users don't know the answer to "should your application use gtk1.2 or gtk 1.3?"
Perhaps a set of tools to try out and manage different version linkings will do what you want?
Static linking may not be an ideal solution for all cases, but its usually an easy one that works for all specific cases.
The GPL does not allow this in all cases (closed software), but what if the GPL were modified in cases where static linking to a library is forbidden.
As long as the publisher makes available a packaged version which conforms to the existing GPL, he may also distribute a staticly linked version as well.
Of course, other "real software" like Apache will work on just about anything.
Yeah, I know a working Oracle setup can do some pretty neat things, BUT Oracle itself reeks of complacency. I see them as your typical 900 pound software gorilla. It would not surprise me if some open-source upstart like PostgreSQL or MySQL eventually gets so close to Oracle's functionality that people just don't bother with Oracle anymore.
Of course, I've seen more big installations where Oracle is falling over every other day than medium size ones where open-source alternatives just keep on chuggin' along...
--
NO TOUCH MONKEY!
I know it's been said many times before, but the key to interopoerability is:
STANDARDS!
I just wish that if we're all going to agree to disagree about the proper use of librarys, wouldn't it make everyone's lives a little better if we could at least disagree in ways that didn't cripple us all?
None of us want to see linux become a jungle of code fragments like that other O$, but it's really not that hard to standardize on a set of fast, stable libraries, and maybe have a few extra-standard sets for some extra functions.
Also, while we're on the subject of development practices #Comment your code please.
The revolution is ours, if we don't make the same mistakes the regimes that came before us did.
I've had RH7.0 since October, and the only thing I have ever had trouble compiling/running is stuff from their "sources" (xxxx.src.rpm). Everything I've downloaded (blade, LAME, kernels 2.4.0-test11 and 2.4.1, e2fsprogs, modutils 2.4.2, etc.) works perfectly fine. Even the pre-built (and statically linked) gpart worked, for which my partition table is eternally thankful....
~~~LXT~~~
Life is like a computer program: anything that can't happen, will.
Comment removed based on user account deletion
Its just common logic. It wouldn't be perfect, but it would avoid source code distribution for source protected software.
Spring is here. Don't believe me, look outside!
Can oracle not distribute object files and then link them on install? This doesn't involve any source code distribution, but allows for the object files to be linked against any C library.
Spring is here. Don't believe me, look outside!
thats why im using w2k atm... but only till i can afford a ppc running darwin or os x
---------------
100% Australian
That's not allowed. MSFT has been doing this for some time with COM, and if MSFT does it, it must be evil.
Java is the blue pill
Choose the red pill
You speak from the point of view of someone who has one Linux box running his application. You download, compile and run.
What about if you're a large corporation? If your app is going to run on all of your many servers - do you really want to have to compile for each? If you want to run it on most of your thousands of desktops - you absolutely don't want to re-compile for each.
My point is that even if you have the source - distributing binary code is extremely useful if not essential.
Oracle certifies platforms for this reason. You will notice they don't support RedHat 7.0.
In the programming language research community, the feeling is that dynamic languages are very good for things like scripting and prototyping, but are not as good an idea for large software systems.
If you are equating dynamic languages with interpreted languages (e.g., most scripting languages), and i'm not sure that you are, then you are mistaken. There are compiled languages that are dynamic (e.g., don't throw a bunch of information away at compile time, allow the definition of new bits of "program" or the modification of existing definitions at run-time, etc.). One is Common Lisp.
The problem is twofold - first, as you mention, dynamic languages always get a performance hit.
The performance hit incurred by good dynamic programming languages is no more than 50% according to comparisons that I have seen, and can go the other way under certain patterns of memory allocation. Again, I'm thinking of Common Lisp.
But the second reason - which you miss - might be more important - fewer errors can be detected at compile time... they would only turn up at runtime, or worse, end up as hard to detect bugs.
Good dynamic languages allow you to OPTIONALLY declare the types of quantities and check these types to varying levels of tightness. Given this flexibility, it is common to develop in a dynamic language with little or no type checking, adding declarations later when the types have been nailed down.
Gee.. What a simple fix. Install the older libc files for backward compatability. That's what I did. It works fine. Just run ldd on the application that you don't have the source for, check to see what libc, and install JUST THE LIBRARIES.. Link all your new apps to the new libc. It works. And it's not the DLL Hell syndrome.
Assuming that at least one thing that the bsd/linux/alternative os movement can agree on is that there must be a viable alternative for wintel.
:P). However, I have at my actual desk in the office a Windows 98 box simply so the potatoe brains around me who occasionally need to use my desktop can get around and leave me in peace.
If you recall when VB was "the" language for writing for windows. There was a dll called VBRun.dll that needed to be on every local machine that executed VB apps. If you installed vbrun300.dll and had a program which was compiled using VBrun400.dll you were out of luck.
I only use wintel solutions where I absolutelly have to. My home computer's an SGI O2. My office real work computer is an i386 running Debian (The only real distro
Using the VBrun example above, I think we need to start looking at a simalar situation for glib. IE find some friggin way to compact and package it with the programs for the potatoe brains invading linuxspace and leave a more robust solution for the intelligent amongst us.
"It's not stealing if you don't get caught!"
"It's not stealing if you don't get caught!"
[Disclaimer: I don't use Oracle at all...I find that most systems which need the "power" of Oracle are simply poorly designed and use horsepower to compensate].
Education. It seems from the threads in the post that the compatibility issues are being dealt with. The above post is a fantastic example of vital development information which I suspect is not known by most programmers. It appears that even "professional" software packages, like Oracle, violate fundamental system-programming rules.
I get lost in the myriad of webspaces devoted to GNU/Linux/Kernel/glibc/gcc/yadayada. Many sites are either too basic, too sparse, too detailed or too out-of-date.
The resources available are as confusing as the collection of EMACS documentation. [I am a big proponent of EMACS use, but the documentation/support information for EMACS sucks, mainly due to its SIZE and its noise ratio.]
We, as a Linux community, need to work on a much cleaner, focused, up-to-date set of information resources.
I don't have the answer to this problem. Please let me know if you do!
Smart!
On the one hand everyone here blasts M$ for "bloat", and on teh other hand they then tell people to use bloat to get round needless bugs in the glibc fiasco! Smart one!
--
People should not be afraid of their governments - Governments should be afraid of their people.
That 800MB includes swapfile, driver databases (that's aobut 100MB alone and can be deleted if you keep your CD handy), graphics, sounds, cursors, and a bunch of other data files.
If you need web hosting, you could do worse than here
While it's true that most users only use about 10% of the features of Word, they don't all use the *SAME* 10%.
Deleting any given feature that's "fluff" to you, will probably piss off 10% of the user base. There are even a lot of people that *LIKE* the damn paperclip.
This is something that geeks don't often realize. Form is as important as Function in order to be successful. You can't succeed if people don't want to use your stuff because it's ugly.
If you need web hosting, you could do worse than here
All you me too! posters better watch what you say. you know Microsoft reads all this. If you complain tooo much about Linux, they'll use it against you, on your superiors, and sell them their product, which forces your using it. If you praise it too much, you'll embarrass yourself in front of us, your peers, and we will mock you as a bigot.
I think it would be best to take the middle path here, if I were youse...
::I will not moderate my opinions for your stinking karma
Then how come one of Microsoft's biggest "innovations" in Windows XP is support for multiple versions of DLLs? Sounds very similar to what has been described here.
---
where there's fish, there's cats
Because Oracle has the most bi^#H a$$ crappy install system in the world for linux. Its the most amazingly crappy piece of $h1t I've ever come across for a long time.
Sorry, but I had to. Mod me down, I'm at -1 anyway. :-)
My other car is first.
I'm kind of tired of pointing Linux towards people that can't use computers (is that a mouse or a CD-ROM). If you can't type
./configure
tar xIvf cool-program-1.0.tar.bz2
cd cool-program-1.0
make && sudo make install
then use Windows. I can, and like to compile everything from source. It's easy; and compatable.
My other car is first.
I am a technician and a hardware buff / end user, not a programmer, so my opinions are less informed than yours on the technical aspect of library compatibility with binary programs. It could be that I am off base altogether, though I think my ideas have merit for users like myself. Again, thanks for taking the time to clue me in.
Thank you!
I was reading all these posts thinking, "Am I crazy? Do I not understand the situation here? Why isn't anyone bringing up version.revision numbering and symlinks?"
You bring sanity back to my life.
"I like to wear big boy pants."
i have zero knowledge of linux
but i dont think oracle would produce, ship or make software for linux , unless it can be installed and work efficiently
i think this problem here is fake !
sheep for the sheep human for the human i just wonna keep my soul alive
This is definitely one of the 2 biggest problems I have with Linux. I use Red Hat 7.0, and I'm still learning how to do advanced stuff. I mainly use it just to do my CS labs because it's easier to connect to the Solaris machines my school has. However whenever I try to install software that isn't a Red Hat 7.0 rpm, I always have some kind of problem. Always. I can't use licq, because I don't have a newer version of qt. I can't install a newer version of qt, because it gives me error messages I don't understand. The list goes on. The other thing is that Linux doesn't have any easy way to set up my Printer (HP Deskjet 810C) or my Promise Ultra66 IDE controller card. The only solution I see for Linux is merger. Every distro, every variation, all the little people have to get together and make one big company. Then take everything and standardize it. combine KDE + GNOME, make rpms standardized, write lots and lots of drivers, etc. If I could I would use Linux all the time, because it never crashes, but sometimes I just HAVE to use windows, because I still don't have the functionality or software in Linux.
The GeekNights podcast is going strong. Listen!
Just support the application in FreeBSD. From one FreeBSD machine to the next within one version of FreeBSD, all the libraries are going to be the same. Exactly the same. Also, if there are a selection of different boxes that you want to install on and they are different versions then use cvsup to bring them all to the same point on the source tree and you'll have a set of identical boxen.
MS probably statically links everything for the same reason I do....you never know what MFC DLL (or other library) the user has. You also never know when they are going to install one of those $10.00 bargain pieces of software that like to go in a hose system DLLs by overwriting old versions without asking. So, accuse me of authoring bloatware!
Of course, the Linux software publishers could just distribute their binaries and ASK if it needs to be statically linked or using a shared library. This would probably eliminate questions about licensing, but what do I know.
So explain to me why I have to reinstall QuickTime, DirectX, etc, every time I want to play a new Windows game? (I only play games on Windows.) Each game requires a different version of the various multimedia DLLs. And Windows provides no mechanism to give each game what it wants - short of reinstalling each time.
Have you noticed the number of Windows shareware products that "manage" a particular set of DLLs prone to version problems (by copying different versions in and out of the \Windows\System dir depending on which app you want to run)?
I run glibc-2.1.2 on linux. Stripped the lib is about 1MB. For Oracle to insist on their own particular version of shared glibc to be installed as your system default in their multi-CD product is pathetic.
Oracle should just link statically. So shold most large commercial products that distribute as object code only with no source.
Whether it makes any sense for there to be commercial products which distribute only in binary is another matter. The copyright cannot be extended under law or even the US Constitution to cover a work whose details remain secret.
Copyright covers published work; trade secret law is an entirely different and weaker area. The US Constitution allows copyright only when intended to "promote the progress of science and useful arts". So there is really no room for closed cource intellectual property.
And only a Bush Supreme Court style fiasco could result in DCMA's anti-reverse-engineering provisions working.
But we do have such a court...
-Brian
I have read more than one post here that says the problem is that you cant write code in C that doesnt encourage tight coupling between application and library.
well it just aint so. opaque types are very easy to produce in C. With these, you can link your applicaion dynamically with its library, and replace the library when ever you want, with no effect at all (as long as the interfaces and semantics of the library is the same). You can add fields, to your hearts content, with almost no penalty, if you pay attention to what your doing, and think things through.
the problem is that the glibc library wasnt written this way, and its way to ugly. it exposes internal structures, which is a very bad thing to do, as we all know. (think objects...)
C++ isnt the only language you can hide implementation details in though.
Just do a google search on opaque types. its possible, and easy, to do in C.
see.. thats your own foolishness, *your* keeping around old DLL's... my point was when MS makes a new DLL, your older programs will almost always still work with the new DLL.. i use a ton of programs.. new and old, new games and old games.. never once have i had a problem running it because i needed an *older* dll file in windows.. have you? i doubt it. Frosty
boy this whole string of messages is a crock, cept the ones that say win9x nt compat are more easier.. true linux has "versioning" and what not, but if any of you would open your eyes wide enough past the "open source is live BS" you'd see that really this is linux's eniter problem.. 17 versions exists of a library, and the only thing you want to do is run one program made for "*nix* and you cant because you have to change 10 files, recompile the kernel, setup 15 other files, and then compile half of the original program you wanted to run.. MS, even though i dont care for windows, or really any bugged to hell OS, they choose to only have one "DLL" per system, you cant have 10 diff versions of user32.dll, only one. now you can argue this "and they outdate the old hardware, etc" but thats more bullcrap, compair windows upgrades to linux upgrades, when MS puts out a new windows (95 to 98) i'd say 99% of the hardware and software still works (and i'd guess 20% even ran better) .. when linux versions come out.. they say use glib xx.x if you have this hardware, and use the whole versioning system deal to use this other piece of hardware , so you use glib xxx.xx for that, it just gets to be crap after a while..
Frosty.
> First of all, a free system is not aimed
> primarily at making binary aplications work, but
> at making free aplications, which comes with
> source, work
Yeah, that's gonna make Windows obsolete for Joe Sixpack really soon. To make any progress, you have to have one simple install icon to double-click.
Ahh, who cares. I switched from Mac to PC three years ago at home because of the games.
I am for the complete Trantorization of Earth.
I tried this one before and it worked:
When a programme searches for glibc 2.1.x (where x = integer) and you have glibc 2.2 installed i make a sybolic link glibc2.1.x which links to glibc 2.2.
It works, sometimes...
So why don't we all make a symbolic link named glibc which points at glibc2.178.978 (whatever version you want) and have all programmes look for the file glibc. This will give some compatibility problems, but I'm sure you guys will come up with something...
It was SP6, and it was Lotus' fault.
MS withdraw SP6, and released SP6a within days, IIRC.
--
Two witches watched two watches.
Which witch watched which watch?
Agreed, and it's not that hard to find things that work on NT & 9x either.
90% of MS products.
Getright.
WinAMP.
WinZip.
Aladdin Expander.
Should I carry on?
On general (very general, though), even thought NT & 9x are very different products, only a low level program would fail.
--
Two witches watched two watches.
Which witch watched which watch?
Support for multiple versions of DLLs is in Windows 2000 and has been since release.
B.L.O.A.T.!!!
The obvious answer is to link statically. However, because of the glibc license, most commercial companies don't want to do that. A better answer is to provide the version of glibc that you built and tested with, and install it as well as your software. You can install underneath your commercial distribution and as long as your software knows about it, that new version won't affect anything else.
Had this same exact problem a while ago after compiling an installing glibc 2.2. My solution was to check out the latest CVS release of gcc 2.95.x, which already had the fix. Even recompiled glibc 2.2 with the gcc CVS release with no problems. Also, haven't had a single incompatibility with the previous glibc 2.1. Perhaps, those folk, can give some specific occurrences of problems they've encountered.
I strongly suggest the original poster take advantage of their site and upgrade the installation as they recommend. On December 18th they released a patch0 79 .html
http://www.redhat.com/support/errata/RHBA-2000-
which addresses and fixes this problem....
1. Topic:
This errata updates the GNU C library to the latest official release (2.2) while fixing several bugs found in glibc 2.1.92-14 and glibc 2.1.94-3.
2. Problem description:
Users are strongly urged to update to the latest official GNU C library. This library provides binary compatibility with programs and shared libraries built for older releases of glibc, such as glibc 2.0.x and 2.1.x.
Binaries and shared libraries built against glibc-2.1.92-14 or glibc-2.1.94-3 are also binary compatible, but new binaries compiled against this glibc 2.2 might not run on systems with older GNU C library packages installed.
I am tired. Really tired. I have been using Linux in the last 5 years, I already installed linux in more than 100 machines and convinced people to use it. It was a mistake... Now I cannot support all this world of 50000000 distributions with 500 kernel versions, 2000 differente libraries and packages. It is ok that is is freedom but we need some organization. Useful work cannot be done in this way. I prefer to pay to someone organize it for me. The free software community lost my confiance. Hence, I am changing today to W2K and will remove my partition linux. I agree with S. Ballmer. bye
Because people do this every day with Windows. They bitch and moan when it gets upgraded and what worked before doesn't work now. So why not apply this same standard to Linux or any other version of Unix?
Silly Rabbit...Sig's are for kids.
So then....stop trying to tout Linux as an alternative to Windows!! It may be another OS but if it is kept the way you want it to be then it will always just be a hobbist OS. Nothing wrong with that but people shouldn't try to tout it as this grand thing that is all wonderful and that.
Silly Rabbit...Sig's are for kids.
Hi,
I read that the upcoming gcc 3.0 will have an "application binary interface", that is a more stable and compatible binary format. If they don't change the signature of the functions in the libraries all the time, this should solve this problem very well.
Another thing: BeOS uses the egcs compiler, and they somehow managed to have very high binary compatibility even with _object oriented_ libraries. For example, they add dummy virtual functions to classes so that the layout of the virtual method table does not change when they add new functions. Linux developers should take a look at this.
greetings,
AC
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Don't let anybody tell you that DLL hell is not a problem under Linux. It is. Our development team specifically runs Red Hat 6.2 Linux rather than the "latest and greatest" so that our software will by default run on the most number of systems out there, and we still have nightmares at times. And software installation is even more terrible than DLL hell -- everybody has a different place they stick rc.d, everybody has different runlevels that they start up in, etc., it's enough to give a guy a nervous breakdown. I finally gave up and simply put a note in the installer, "Plunk a reference to script [xyz] into wherever your Linux wants its startup scripts" and tossed up my hands in despair. Coming up with an installer that would put something into the startup sequence on Slackware, Debian, SuSE, Storm, Caldera, Red Hat, and TurboLinux was an AI problem, not a job for a shell script slinger.
Of course, this is how the distribution vendors want it. When it came time to package up RPM's for Red Hat, it was ridiculously simple to fix my little servelet to start up at system boot, just toss the start script into the right place and run the nifty command that Red Hat provides for that purpose. That's how Red Hat wants it, because that way it's tied to their version of Linux.
Not that the proprietary Unixes are any better. I curse Solaris every time I have to touch it (did you know that the only way to get a list of all SCSI tape devices on Solaris 2.8 is to do a 'find' on the /devices directory, but *only* after running "usr/sbin/devfsadm -C" because otherwise you could have some device nodes in there left over from drives that no longer exist?). I can't get Xemacs to install from the package files on IRIX (looks like I'm going to have to compile it from source, oh joy). HP/UX has a broken 'uname' command (how the BLEEP can a vendor break uname?!), though at least I manage to get "HP/UX" out of it. Creating a shared library on AIX is deep voodoo requiring encantations and lamentations and really only works right on the very very latest version of AIX (don't even *try* it for two versions back, it won't work). As pissed as I get about Linux vendors and their habit of breaking the world every six months, at least Linux stuff generally works and is easily fixed when it doesn't.
Note: I speak for myself, not for my employer. My employer specifically disclaims any statements I make about idiocies that OS vendors perpetrate.
-E
Send mail here if you want to reach me.
Why do I say that? The glibc team did their best to maintain compatiblity from glibc 2.0, to 2.1, to 2.2. The only time this isn't true, and isn't a bug, is if the application used some glibc internal function. This is why things like star office (5.0 or 5.1, I forget) broke from 2.0 to 2.1. It's also probably why Oracle broke. But, if it's not the case, file a bug report and maybe it can be fixed for glibc 2.2.2.
When you use emacs that way, it only requires 125% of system resources, rather thant 250%.
Bah, damned EMACS hating fances of the One True Editor . . .
:)
hawk
> Everyone misunderstands Emacs.
:)
See, there's the problem. It's mother didn't love it, it's father abandoned them, and a cruel society led it to it's life of crime.
:)
hawk, replying twice to the same message, bad form or not
>Resources under GNU/Linux (and other POSIX) systems are called things /var/tmp," "processes," "LWPs,"
:)
:).
:)
>such as "memory," "free space in
>"texture memory," etc.
Yes, theat's also true under Linux, and X/Perl/BSD/NSF/Apache/GNU/Linux,
both of which are far more widely used than GNU/Linux, which is useless
without the rest.
The term "system resources" predates both Unix and the *existence*
of microsoft by decades (as does Emacs piggish behavior, iirc
>But when a resource is actually called "System
>Resources(TM)", and it's measured in percent, ten bucks says it refers
>to [23]the 64 KB USER and GDI heaps in Win32, which can't be enlarged
>without breaking Win16 apps. (See also [24]Resource Meter.) I see no
>analog to the 64 KB USER and GDI heaps on POSIX+X11 systems.
nope. I'm not referring to them at all. Just the plain old ancient
reference to taking everything the system has, and then some
hawk, who hadn't thought himself old enough to be a curmudgeon.
As Linux's primary commercial role is in preconfigured appliances with no user interaction, the job of matching point releases is only done once in the life of the machine. In the future I expect even the bedroom use of applications on Linux to give way to one-time configured appliances, each with its own set of library versions.
Also, it wouldn't so much figure out where the function was on that system as much as re-use components from a core set of dynamically loadable files, where one function call = one file.
(What you'd end up with is a virtual GLibC that is built out of only those components you're using, be upgradable without interfering with dependencies (as the dependencies would be on the scripts used to generate the call, not on the implementation), =AND= avoid unnecessary duplication.
(One of the really horrible things about the existing way of doing things is that you can easily end up with a hundred nearly identical libraries, doing essentially the same basic stuff, but NOT exploiting any re-usability in anything else that's out there. Hey, folks! That's stupid! Recycle what you can't re-use, just stop re-inventing!)
My "ideal" glibc would be a script which searched through an index for all functions meeting some stated criteria. There may well be duplication of functionality, but that wouldn't matter, as the different implementations would meet different criteria, all accessible through the same API.
The "central library" would then merge these DLO's in with the script, to "create" the actual functions the apps are going to call.
This is superior to the Windows model, as you're not reliant on specific versions of specific DLL's being present, and upgrades can be done on the fly. (DLLs cannot be easily upgraded when in use. In this model, the application never sees the actual implementation, only the interface, so allowing for on-the-fly upgrades.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I was thinking along the lines of each "function" carrying the actual call, a summary of the pre-conditions and a summary of the post-conditions.
When you make the call, you define your parameter list, and your own pre-conditions and post-conditions. It is then up to the GLibC "wrapper" to mix-and-match what you're sending & expecting with the functions that are available.
This would essentially do the same as the versioning map, but would have the advantage that the computer would take care of which version is good for what.
eg: If you call a function "blort", with a given parameter set, no pre-conditions, but the post-condition that the output will be a value between 0 and 1 (0 = OK, 1 = Error), then GLibC should cheerfully ignore all "blort" functions that return values outside that range.
This is the same as your parameter declaration, with one small difference. With pre- and post-conditions, you can combine the inputs and outputs of functions, to see what the net output will be. This would simplify making composite functions.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Well by that argument someone could replace everything in /usr/lib with bash scripts and kill Unix. Yep, you replace system files with nonsense and things won't work.
How do you prevent this from happening on Unix? Well the files are only writeable by someone with root access.
This is also true of Win2k, the files are only writeable by someone with Administrator.
Without having different types of user security access, or by burning everything to ROM, I'm not quite sure how you suggest resolving this issue.
I don't appreciate it when obviously uninformed people try to claim I'm wrong.
I verified this fact before posting my original message. The system files are not world writeable on Windows 2000.
Not even by default.
You had better go reevaluate your preconceived notions because it seems the world has turned upside down on you.
Use the -i (install) switch instead of -U (upgrade). It will keep the old libraries on the machine instead of removing them, which is what upgrade will do.
the good ground has been paved over by suicidal maniacs
There is no glibc compatibility problem. Properly-written programs have no problem whatsoever. If, however, programmers use calls that are internal to libc -- that they are told NOT to use -- then what do you expect? They have violated the rules, and it's coming around to haunt them.
I routinely run binaries from pre-2.2 versions of glibc on glibc 2.2 systems, and not only on Intel platforms. I have experienced no difficulties thus far, with either binaries shipped with Debian or otherwise. I do not use Oracle, though.
Perhaps an analogy would be useful. In the days of DOS, applications could totally bypass the operating system for basically any purpose. (Granted, because the OS stank so badly, there was often justification for it.) But when people tried to start using systems like Windows, many of these apps broke -- assuming that they had total control of the machine when they didn't, because they violated the rules before.
In this case, there is no need to violate the rules and frankly if programmers are stupid enough to go out of their way to find undocumented calls liberally sprinkled with warnings, and use them instead of their documented public interfaces, I wouldn't buy their software anyway. PostgreSQL doesn't have this problem.
There's this little ABI that Microsoft published, called Win32- it was to this that he was referring to, not the DirectX ABI, that largely works only on the Win95/98/Me platform line.
Applications written to the Win32 layer are supposed to work- no matter what. It's this ABI that Office 95/98/2k were written- and they install the same set of binaries for all Windows platforms out right now. This means that applications written to the Win32 ABI should work fine on Win95/98/Me as well as WinNT/2k/XP- no matter what (It's what MS has been saying all this time...).
You know what? They DON'T. Especially if you're dealing with the GDI layer- that's toast (even though it's all part of the ABI...). There's bizarre behaviors that you've got to find out for yourself (because they're not even documented in the MSDN CD sets or anywhere else...) that cause a nightmare for supporting things like document imaging, etc. on Windows platforms. I know I did that for approximately 3 years at a previous job where I wrote OCXes, then ActiveX components to allow VB and other development platforms do document imaging on Windows more easily.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Ok, I should have formulated that better...
Shared libraries lose their big benefits when every binary ships it's own version of that shared library. On win2k that has become the rule now, to avoid library version conflicts.
On GNU/Linux (and most other systems), you *can* ship a separate version of that library with each binary that requires it. But the libraries will be installed at the standard locations, so if more apps require the same version, they will actually share the library. This is what RedHat used in the glibc-compat package, which provides a compatibility library so that RedHat 6.2 binaries will run flawlessly on RedHat 7.0, using the proper versions of their shared libraries, while the "native" RedHat 7.0 binaries run on the newer libraries. Simple, elegant.
Our Linux apps (currently on RedHat 6.2 only) ships with a special libstdc++, which we will probably be the only ones using. However, because of RedHat's approach, we will not do this in the next release, it is perfectly reasonable to simply use the compatibility libraries on 7.0 and the native libraries on 6.2. Once we start supporting a stable 7.X platform, we will of course run on the native library versions there.
On NT and Win2K we must ship specific versions of some DLLs in order to get anything running. There is no backwards compatibility, and there is no DLL versioning. It is of course very simple to just ship your own DLLs, and it works perfectly well, I am just arguing that I fail to see the problem with the GNU/Linux (and most UNIX like systems) approach. Especially given great vendor support such as what we see from RedHat (and probably others too).
Huh ?
I'll check up on the DHTML thing tomorrow when I've gotten some sleep...
The network monitoring system is a client/server system. The server is a large program (it is a distributed database and a remote monitoring system), and the client is a very small easily portable program.
Thus, the server is available for RedHat 6.2 (and therefore also 7.0, the 6.2 version will work there), Debian 2.2, FreeBSD 4.0, NT 4.0 (and therefore also Win2K).
The client is available for the same platforms, plus, RedHat 5.2 (with a Linux 2.0 kernel), and FreeBSD 3.4.
As you will have noticed, the software is in beta, but we are *very* close to a release. There are bugs left, but we will have a release out fixing the last known ones, probably around the weekend.
Should anyone out there have oppinions, suggestions, demands or "other", for a commercial program soon-to-ship for Linux among other platforms, I would welcome such feedback.
Please use this e-mail address and check out the website.
And please accept my apologies for going slightly off-topic on the subject here.
There is lots of other overhead of shared libraries, which people seem to be blind to. The overhead on each call is not zero (on the best systems it is only significant on the first call, but even then I suspect there is overhead because of non-contiguous locations of procedures verses static linking).
I don't see how putting the shared library into the bundle is going to help. If the system could identify it as matching another shared library and thus sharing, we would not have the dll problem in the first place, as that same library could reside where libraries normally do. If not, you have just added all the overhead of static linking AND the overhead of shared libraries.
Conversely, though, RTTI would be simple and almost free (the vtbl pointer could be used and a single pointer added to it to point to the parent vtbl) if it wern't for damn multiple inheritance. C++ really fell down when they gave into the demands of those idiots who wanted multiple inheritance for non-pure-virtual objects. I do believe everything could have been done with a single parent, and some syntax for invisible ONE WAY casting to the other "parent" types, ie the class is only of one type, but can be easily used in calls that accept any of the other "parent" types.
If you think using compatability libraries isn't adequate, please explain WHY, in technical terms (i.e., not "It seems yucky so I don't like it").
Also, under the LGPL, you can't distribute statically-linked versions of an executable without also distributing the unlinked .o files as well.
Engineering and the Ultimate
How do you use symbol versioning?
Engineering and the Ultimate
A while ago, as an experiment, I installed the glibc from RedHat 7.0 on a 6.2 system. Almost everything worked exactly as before, the only thing that broke was Emacs due to some problem with Berkeley DB.
So I'd say it is Oracle that's being downright stupid. I don't know what is meant by 'tries to relink itself with the new library', but it sounds pretty unpleasant and unnecessary. Hundreds of other binary packages just kept on working when glibc was upgraded.
Oracle is well known for being a pig to install and get running, and this is just another thing to add to the list.
-- Ed Avis ed@membled.com
Oficially, glibc2.1 was not a production release but development. If glibc-compat is not acceptable on a production system, then software linked to a non-production library should not be acceptable either.
For prople primatily interested in Linux, and glibc2, there's a paper for the community, written by David J. Brown and Karl Runge on Library Interface Versioning in Solaris and Linux.
(David J. Brown is the originator of the Solaris Application Binary Interface programme: I worked for him for two years on the project, back in my pre-samba days --dave)davecb@spamcop.net
Man, this is an awesome idea. Has someone done this already, or did you come up with it?
Glibc 2.2 is suposed to be backward compatible with 2.1 (and 2.0). I am running 2.2 and have not had any problems with programs built against 2.1 (and an even running some built against 2.0.7). The library which seems to cause problems is not glibc but libstdc++.
You have no clue what you're talking about.
Here, I'll make it simple:
With Windows, there can only be one version of a library usually, so you're just screwed unless you have source.
With Linux, you can put as many versions as you need for compatibility, and use symlinks to make as many applications see them as necessary.
If your application requires libfoo.so.1.1 or greater, then libfoo.so.1.1.x (where x is any number at all) should all be compatible. If they aren't, it'll be libfoo.so.1.2.x instead.
So put libfoo.so.1.1.7.8.3 on the system, and create a symlink so that libfoo.so.1.1 points to it, and all is well.
Applications that REQUIRE libfoo.so.1.1.7.8.3 will be happy, and so will applications that require any 1.1 or later, and if necessary you can also put a symlink for libfoo.so.1.1.7 pointing to it.
Can't do that with Windows without putting a seperate file for every one, because symlinks aren't supported.
All I have to say is the farthest lefthand digits my application requires; probably 1.1+.
As for RPM dependencies, that's a packaging system, not an operating system. You can even use it on Windows, but you don't attribute it's failings to Windows, do you?
If somebody chooses to package their application in a certain way and not any other, you should direct your blame to the application distributor, not the OS author.
-
> Linux/x86/glibc-2.2 - 310696 (76 pages)
Damn! And I thought Delphi Hello World! programs were pigs at 270K. Of course, it remains to be seen how bloated Kylix programs will be.
> Yet her you are advocating EXACTLY the same approach to get round the glibc fiasco.
I believe he's not thinking of static linking as actually "shipping your own shared libraries", which in essence it really is.
What's wrong with this? After all, what is a circle but a polygon with an infinite number of sides? :-)
---
"They have strategic air commands, nuclear submarines, and John Wayne. We have this"
Hacker Public Radio is our Friend
On my system, I have 558 different packages. To compile all of them from source would take days, if not weeks (I know compiling X would 3+ hours).
It's nice that you have the time to recompile all your programs from source. I don't.
Je ne parle pas francais.
When using real software like Oracle under linux, you find out what the requirements are for the application you're going to run, and install a compatible setup.
<p>
Yes, but I think what the questionner was getting at is that this is NOT the way it should be.
<p>
-josh
So far I have seen many people pose solutions for running glibc2.1 and glibc2.2 together on one system. Or to get your RH 7.0 to have glibc2.1 libs on it. Someone even said that this is really a none issue since you can run 2.1 and 2.2 on the same machine.
I think you ALL missed the point. The question is really WHY are there so many incompatiblities between 2.1 and 2.2? These are MINOR revisions. Going from libc 5 to libc6 was considered a major change. One had thread support one did not have very good thread support. Plus there were other changes.
I noticed that developers in the open source community are more for lets make this revision better and fix these bugs, but screw it if it does not work with the previous software revisons, people can just upgrade or recompile the old software. This is the general attitude. That and oh they can keep multiple revisions of the libraries (gtk+1.0 and gtk+1.2 rings a bell). Hey just look at kde. kde 2.0 was so different from kde 1.x that You basically had to uninstall (kde) and reinstall (I did). The whole architecture was that different.
I have used windows and between Win 3.1 and Win 95 there were problems, but I do not have that many between 95 98 and NT 4.0. (Oh and I do use Linux as my primary system).
One of the things that open source groups try to do is to get the program 'right'. While this is good, they often overlook those of us who don't use a particular distribution (or rather would not), and they say well let the distributions figure it out for the community and anyone else can get the source. Redhat tries to do this (and of cource they add there own stuff) and then you end up with them releasing something like RH 7.0 which so many people have had problems with.
What ALL these people either fail to realize to maybe it's that they just don't care, is that no mater how easy of a GUI Linux has with kde or GNOME, and how easy of an installer you make, when someone wants to upgrade one package on their system if there is not an easy way to do it then they run into the problem that this person has. Trying to run a program that comes in binary form only with a library that it wont work with.
Is there a solution? I say yes, but it lies in the hands of the developers to say lets get it right the first time. How can they do this. They can try using a design and a design document first rather than just coding and making changes later. The other thing they can do is eliminate scope creap. Scope creep is what happens with the Linux kernel. They say we will fix this and that in development x.x.x and then they start finding other things to fix and start work on those systems as well and the whole development cycle takes twice as long. Then by the time that they are done the whole architecture has changed and they have done more then they planned. (Scope Creep).
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
Because that generally requires predicting the future, which is effectively impossible. An application that is designed to link against glibc 2.1 would have to have anticipated the changes in interface and functionality in 2.2 to be able to work with 2.2.
True forward compatibility would require some kind of interface and functionality discovery mechanism, in which an application says "I'm looking for a version of function x which has such and such behavior", and is then given a reference to the appropriate function by the OS or some other middleware like CORBA or COM. These systems do support a weak form of interface versioning based on a version number. However, all such systems still require you to keep earlier versions around, so you won't easily get away from the requirement to maintain old library versions.
What is there to linux if you have to hack a system together that is totally incomprehensable to proffessionaly maintain on a commercial software level (ie, not having the sourcecode like in the original question).
The basic issue is not specific to any OS or language: it's a simple logical constraint. Why can't an old vinyl LP record player play CDs? Same reason.
You have no business running quake on an Oracle server.
I am talking specifically about oracle here. This is not a home user application. The problem you are discribing is valid though, just not addressed in my post (or the parent post).
Hmmm... I really don't get your point. If Oracle (for example) says that it needs RH6.2, it will run on RH6.2 regardless of who loaded it. Yes different people laod different software (full install versus custom install) but that doesn't affect the libraries. That's what we are talking about here right? Do you have an example of this not being the case?
The parallel between the service packs (which are different versions of dlls/libraries) is perfectly valid in a sense that companies like Oracle have very specific requirements, and people that uses these big time applications follow these requirements to the letter. I think that's really all the poster was trying to illustrate: the "other way around" fact.
No to trash open source project like progreSQL or MySQL (I am all for them and use them) but Oracle is currently (still) in a completely different league. The number of features it has is astounding - I have just discovered lots of them recently in training. Of course, I'll probably never need to use these features, but that's just me - the right tool for the job.
And the issue here is not "faky behavior", it's the fact that Oracle doesn't distribute the source and it won't link because of the different libraries. Now we can start an argument that Oracle should distribute the source code, but that has basically no chance of ever happening.
For another example. Buy a RedHat 6.2 based server from VA Linux and that has different software from the RedHat 6.2 you buy from RedHat as well as the RedHat 6.2 system you can buy from penguin computing.
This "Service Pack" thread of NT is BS as well. If it was as simple as running linux with Service pack 1 then by all hell that would be easier then saying "This software must run under RedHat 6.2 with rpm updates blah blah and kernel version 2.1.17-28"
Atleast i can install oracle (again, an example) on Solaris 8 because i know solaris 8 is certified. Doesn't matter if i have Sun come in and install it, its still solaris 8, doesn't matter if i hire an outside consulting firm to install it, still solaris 8, doesn't matter if i get it pre-installed, its still solaris 8.
Linux doesn't have anything close to a "foundation" for an application framework (such as oracle and oracle applications) to build from and such you have to run features so specific its not linux but Redhat.
Back to my original question, why call it linux or even compatible if each distro and each version is so different that you have to be so specific?
Atleast with NT i know if it says Service Pack 3 i can Buy a server from Dell and specify service pack 3, but with RedHat there is no standard, not even within there own versioning. RedHat can't say "Pengiun computers must use the base install + drivers and optional support".
This really won't go anywhere, i just wanted to see peoples opinions on it.
Is the beauty of linux that linux isn't linux but everyone can make there own distro and nothing will ever work fully because everyone has there own idea of how things should work?
So is glibc2.1 and the listdc++ changing so much to support new hardware/new kernels and new features that old and working systems cannnot move forward?
Ofcourse you need to certify your business applications against a specific environment. But my question is how can we have so many vendors each calling there system Linux but we all have to run RedHat 6.2 because that is the only supported linux?
The SP fix is just BS. If it was that simple then i could apply the service pack on any "linux" distro because they're all functioning in the same so called way.
Why can't things just be fowards compatible? I'm not talking about linking against glibc 2.2 and running on glibc 2.1, i'm talking about why do apps linked against glibc 2.1 fail under 2.2?
And thats not all of it either. You can't just say requires glibc 2.1.3, you have to say Requires GLIBC 2.1.3, RedHat 6.2, Redhat upgrade of so and so rpms, IBM's java sdk 1.1.8 and kernel 2.2.17-24.
What is there to linux if you have to hack a system together that is totally incomprehensable to proffessionaly maintain on a commercial software level (ie, not having the sourcecode like in the original question).
Surely C suffers from this problem, though? It's possible, IIRC, to (under some circumstances IIRC - I'm not a C expert) write a value of one type to a variable of another directly, while it doesn't check the bounds on an array. Both produce strange errors which aren't that easy to spot as the crash happens when the wrong data is read (could be at pretty much any time) as opposed to when it's written, plain and obvious for all...
Greg
(Inside a nuclear plant)
Aaaarrrggh! Run! The canary has mutated!
If symbol versioning takes care of this issue, then let me get to my favourite rant about stinky rpm (did I mention that it stinks?)
What is an ordinary Linux person (i.e. me) supposed to think when trying to 'rpm -U' the next version of glibc and a billion dependency complaints come back? This is just wrong. And do you get any help on whether it's safe to force the upgrade? Not by rpm, you don't.
Half-useful / half-dopey programs like rpm give Linux a bad name.
And, by the way, if symbol versioning is good, why is it even an option to build without it?
Redhat 7 uses non-standard C libraries and C compiler. Both are development releases, not 'stable' releases. I've seen quotes from Linus himself that RH7 as a 'development envioronment' is completely unusable. RH7 is even binary-incompatable with other Linux distributions.
Wait for 8, when hopefully redhat will correct their mistake and ship with stable versions of C libraries and C compilers.
-- Greg
Slashdot, would a spell-checker for posting be too much to ask? It's not rocket science!
Not true.
there are literally thousands of crucial dlls are writable by anybody.
the winnt directory is world writable and so is the system32 directory. Anybody can alter any one of them and bingo a broken system.
War is necrophilia.
There is nothing preventing anybody from creating a dll called wininet.dll and stamping it with version 99. You can do this in VB. Then anybody who installs this program has a broken windows from then on.
War is necrophilia.
Yes, rpm is a pain in the ass. I much prefer the packaging software that's been around a lot longer, like that under Solaris or Digital Unix or IRIX.
And, by the way, if symbol versioning is good, why is it even an option to build without it?
Because it isn't easily automated. You must choose which symbols get exported, which get restricted, and what version number goes with each symbol. Some symbols (which ones?) might get their versions incremented (by how much?) for a particular build, and some won't, depending on you and your app.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
The easiest solution, one which I have recommended to the company for which I work, is to statically link commercial products. That way, you don't need to worry at all about what libraries are installed. It's much easier for the users and the tech support people. IMHO, more Linux apps should be distributed as both static and dynamic, so that more intelligent/experienced users have a choice.
Also, it's a fairly good idea for people to have older libraries installed on their system. I don't see why you wouldn't, except if you're out of disk space. In that case, just go out and buy a 20GB IDE hard drive for $99.
I've experienced this problem. I once had an application I needed to get running that involved two different database applications: Oracle and VSystem(a real time database). The problem was, at the time, VSystem would only run on RedHat Linux 5.x and Oracle would only run on RedHat Linux 6.x. Because we had to link the two programs with callbacks, the compat libraries were not an option.
What I ended up doing was putting them on two different machines and writing a glue program with Perl::DBI . There is now a VSystem for Linux 6, but we are still using the version I wrote with Perl, because there is no reason to switch.
Yes, this sucks.
--- "So THAT's what an invisible barrier looks like!" - Time Bandits
Hmmm... read up on the LoadLibrary call in the Win32 SDK. You can solve the problem of DLL versioning by putting a copy of the DLL you need in the same directory as your application. It will be loaded first, before any of the libraries in Windows\System(32).
It's not as nice as the *NIX way, but it works.
Not that I'm advocating this for Linux but this is the main reason for all that COM groat.
One alternative is to number the dynamic shared objects and have the linker automatically resolve to the right dso version. For compatibility you just install multiple versions of the same dso in the lib directory and each app should resolve to the version they were compiled against on the development system.
Shared object code should be kept in version specific folders, i.e.:
When a app starts up and links to a .so - it should enter itself it that
version's used_by.txt file (unless it's already there). If a newer version
is available it should notify and ask the user if they would like to try the
newer .so or to stick with the old one. Either way they can check off a
"...and don't ask me again for this application".
If the program crashes while using a new .so (while making a library call?)
it should flag itself not to ask again, as it seems incompatible.
If the program successfully completes it could flag itself as working with the new .so and remove itself from the old .so's used_by.txt file and add
itself to the new .so's used_by.txt file.
When a .so is no longer used by _any_ applications it would be (re)moved.
That sounds pretty safe.
Of course this should all be implemented in a invisible manner to developers. And why don't we solve hunger and war while we're at it?
You mean the app would just need to know the name of the function it's trying to call, and the API layer would figure out where that function actually is on that particular version/system?
;-)
And significant API changes would create new names of the function (GetFileLock might become, say, GetFileLockEx when new parameters are added or its return value types or meanings change)?
So, like Windows?
-b
If I wanted a sig I would have filled in that stupid box.
Hmm. I was being kind of facetious, but now I'm interested.
Overloading APIs is an interesting idea, and it solves some of the problems. You'd also have to handle an arbitrary return value; if an older version of GetFileLock returns 0=Failed,1=Worked, what are your old programs going to do when the new version returns 2=Deferred (or whatever)?
It seems to me that in order for this scheme to work, apps would need to tell your virtual GLibC each input parameter and type, and what output parameters they can handle. Alternatively, each function could be strongly versioned and there could be a compatibility map, so when an app wants GetFileLock v2.5.1, the central script knows that 2.6.3 will work, but 2.9.1 won't.
I don't like the one function = one file idea, simply because 1) You'd end up with thousands and thousands of API files, so 2) it would be next to impossible for software vendors to specify "known working" configurations.
You're only partly right about how Windows works. While DLLs cannot be updated while in use, increasingly MS is going with a "different DLL for each version of the library" approach. It's all about objects and object ID's these days, so the actual DLL's don't matter as much (where having two versions of the same DLL with the same name in different directories used to wreak havoc, if they're different versions today, they'll register different object ID's and everything will be fine). If you install an app that wants a later version of some library, it can install that later version and register it, since those object ID's aren't in use, even if an older version is. Hopefully that made sense.
Of course, this is only true of modern, COM/ActiveX based apps that create objects based on object ID, not DLL name/function name.
Apps specify the object ID that is unique to the library version they were written for (eg my app uses the ADO 2.6 library, but the ADO 2.5 library is also around and can be invoked by older apps). That works, but it doesn't get rid of the "multiple versions of the same code" problem. In fact, it makes that problem worse.
And while there's nothing to stop the OS from going out and getting ADO 2.6 if it's not installed, functionally that's not happening right now.
It's an interesting problem. Basically any solution is going to add some overhead and complexity, but it's probably well worth it.
Maybe the answer is tighter API/code integration? For the sake of argument, look at it in an OO light; maybe the program asks some API what parameters it will need to supply to accompish something, and then makes the actual API call with those parameters? Likewise on the return codes; some sort of metadata about what the return means?
Cheers
-b
If I wanted a sig I would have filled in that stupid box.
Hmm. I like the pre and post conditions, but doesn't it get thornier for more complex return values? Like, say, a pointer to a struct rather than a boolean value?
The API matchmaker would have to be able to parse and understand structs, which I guess is ok.
And if you look at your blort function, suppose a new version returns 255 for "OK, with a warning". The GlibC can't consider that a function that returns between 0-255, because a later version yet might return 2="Will batch process tonight". The problem fixes itself if you force tight enumeration, but is that really practical?
Interesting stuff. Are there any good books on the topic?
-b
If I wanted a sig I would have filled in that stupid box.
So you want me to go do my chip design work on some form of Windows, then?
I'm trying to get the chip design job moved to commodity PC hardware, using Linux. Guess what, we may be able to program our way out of a paper bag, but that's not the job at hand. I need to spend my time on my primary job, not settling glibc incompatibilities.
Windows is starting to become practical for chip design, but the opportunity for Linux is still wide open - for a while. Last time I tried building the gEDA suite, I had to give up after a while - there just wan't time to get all the library issues resolved.
The living have better things to do than to continue hating the dead.
Yes, and I tend to agree that an editor should be extensible in this way. Extension languages are cool! But I don't think that having a small, extensible core makes the system fundamentally "small".
The problem is that the extension components are inextricably tied to Emacs. They don't do "one thing well" in the traditional sense, because they can't be used by arbitrary other programs, ony Emacs. Even within Emacs, their interfaces make them much less reusable than Unix utilities that communicate mostly by command name, stdin, stdout, and exit status. Thus, I think it is only fair to call the Emacs core plus the set of extensions you are using a single whole. And that's "big".
If you startup a barebones version of Emacs using "emacs -q", you will get an editor that starts up instantaneously, consumes little memory and is lightning fast.
Isn't that emacs "binary" an undumped image with all the required lisp already byte-compiled?
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
That is the way it is on *any* platform for applications like this. Oracle does not claim to support or have their products ready to be used on "Linux" They have support for it on RH 6.2. You will find that in the winders world they specify service packs. And that for other flavors of Unix they specify versions, patches, and kernel parameters. With big time software this is the way it works. And truth be told that is the way it should be. Simply put if Oracle tried to support and run on every possible version of every platform out there it would not be too long untill they could not really support or run on anything.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
That would be wrong Linux is the kernel nothing less and nothing more. RedHat 6.2 is a OS that is the OS that Oracle supports. Debian is a OS it used the same kernel and many of the same tools as RedHat but it is *not* the same OS. There is more to the OS then the kernel. Also if you are running a Oracle server on a RH x.0 release you are insane. Redhat will support 6.2 for a *very* long time because they understand and are honest about this point.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
i don't know about everyone else, but I blast Microsoft for bloat in the sense that Word includes everything but the kitchen sink despite the fact I doubt very much if anyone uses more than 10% of the features in Word. Big hulking programs due to feature bloat is a what I think of about Microsoft. But then, I'm not enough of a programmer to get pissed about code bloat due to static linking.
Be ot or bot ne ot, taht is the nestquoi.
So you think Office is good because it consumes a little more space than StarOffice???
I won't even argue with the logic of that. I don't like or use either product.
Let me put my original point another way: MS Word 5.1 for Mac was small enough to fit on an 800k floppy with room left over (OK, if you wanted spell-check, two floppies). As far as I can tell, Word 9x/200x [may] provide marginally more functionality while consuming 2 orders of magnitude more space. That is what I call bloatware. Lots of feature creap that does not help me type documents any better, but sure as hell makes the whole program bigger and slower. Oh yeah, Word 5.1 for Mac was statically linked. No extensions/libraries/anything.
Be ot or bot ne ot, taht is the nestquoi.
Comment removed based on user account deletion
So while we're whining about a binary incompatibility issue that is well known and been discussed to death, can we add in pleas for venduhs of commercial proprietary everpresent software (like Shockwave/Flash and PDF) to please start recompiling every piece of software they make/release for each architecture as well as each version of Red Hat? I can't begin to recall all the times I've downloaded a "linux" version of something for my PPC that didn't work. And don't even get me started on source distributions that don't compile from source because the developers don't seem worried about protability in the least.
The age old wisdom of pick the software you want to run, then find a system that runs that software applies here.
I do not have a signature
I'm running it, thanks to this page.
change me
I've not had any problems with glibc. All of my problems with running binaries have been with the libstd++ library.
However, there's nothing to stop you from having several versions of the libraries, which (in my cases) have fixed the problems.
Oolite: Elite-like game. For Mac, Linux and Windows
would take the source and compile, then install the program. For the end user short on time or technical ability this would be transparent and just as easy as installing a binary. In addition to the the easy installation and solution to minor incompatibilities from library version to library version there is also the performance benifit of compiling the source over using a generic binary.
Everyone misunderstands Emacs. Emacs is NOT bloated. It is "extensible". There is a difference.
All the extra functionality in Emacs is implemented through the use of Lisp packages which are not loaded unless the user explicitly asks them to be loaded.
If you startup a barebones version of Emacs using "emacs -q", you will get an editor that starts up instantaneously, consumes little memory and is lightning fast.
Magnus.this kind of elitest stance will do absolutely no good for linux, open source, or any of the stuff that we seem to hold so dear here on slashdot.
.so hell, in this case), but it takes work, and forethought. hacking together a library just wont do it. unfortunately, the clibrary was written a long time ago, and there is almost no chance of getting it rewritten using better opaque types, and hiding its internal implementation.
The customer is not just a dumb lump that needs to get out of your way. they are what makes your software viable. with out them, your just a lone hacker hiding in your room, writing stuff noone will ever use.
Telling them they just shouldnt use that stuff that wont work with the newest linux glibc is not the answer. providing ways for vendors to provide glibc neutral software is. Having oracle for linux was one of the biggest wins linux has had in a long time, makinng it seem almost viable to the business world.
It is possible to avoid dll hell, (or
But that is the only way to make this problem go away.
In a home user world, sure, you can pick your OS and then install whatever software yu want/can get to work.
The business world is a different matter. The rule of thumb in business is that you specify and purchase your software that you need to do your job FIRST, and then install the OS you need to run the software.
If Linux is to survive in the business world, there needs to be a shift in thinking away from the 'OS first' model. On the other hand, verndors need to be absolutely specific as to what target they built their applications, so you have some idea what you need before purchasing.
Little girls, like butterflies, need no excuse. -- L. Long
Ok, I don't think you understand at all what DLL Hell is on Windows. Your assumptions as flawed at any rate.
:-)
The problem with DLL Hell under Windows has nothing to do with a lack of versioning. DLLs do have versioning, and Microsoft has tried to always be careful in leaving old interfaces compatible so as not to break upward compatibility. In cases where they clearly have to break compatibility they do the same thing as Unix... they create new files with new names.
VSVBVM60.DLL was a replacement for VSVBVM50.DLL which left the 5.0 functionality intact. However there have been like half a dozen versions of VSVBVM60.DLL released which fix bugs internally without breaking external interfaces.
With COM you don't even care about the filename since all interactions with the component are through the ClassID. You can create a new file, with a new name that registers the same ClassIDs as the old component and redirects them internally as appropriate.
There are differences between COM and classic DLLs and I'm going to talk about classic DLLs primarily because that's where the DLL Hell problem has occured primarily.
Now one problem with classic DLLs is that only one copy of a DLL is ever loaded into memory, and this has created many problems. This isn't completely true under Windows 2000 which has additional new features I'll mention later.
Where DLL essentially comes into play is from REALLY STUPID BRAINDEAD INSTALL PROGRAMS! Not to mention Microsoft's lack of attention to this problem existing and unwillingness to do anything about it, even if it was just education.
As an example, let's say you have version 4.1 of generic.DLL installed on your machine by application X.
Application X works fine.
Now you install application Y. This install program installs a copy of generic.DLL version 4.0.
Now application Y's install program is broken, it either does two stupid things, it installs this old copy of generic.DLL over the top of the newer copy already in windows\system. Or it places it in the application directory.
In the latter case, if you run app X before app Y everything works fine. But if you run app Y, when the system searches for the DLL it finds one in the app path first and loads that. All subsequent requests for this shared DLL are passed the pointer to the one already in memory.
In the former case, app X is never going to work if it relies on functionality which existed only in the newer copy of the DLL that it had installed. app Y broke it permanently by stupidly overwriting a newer DLL.
Similarly with COM DLLs one could overwrite a newer version of a control with an older version which breaks assumed functionality.
The solution is actually really quite obvious in 95% of all cases. Most of these DLL problems result from shared DLLs as part of the OS or distributed with the MS Development tools. The solution therefore is to only allow Microsoft to distribute and update these via Service Packs. This is the path they have finally gone down in Win2k.
That is to say these MS shared system DLLs should never be deployed with an application. If your app needs a certain version then you should specify that you need Service Pack 4 or whatever.
We'll see if this happens with say Office XP.
You then only have an issue with shared third party controls. Now this can be solved by using Win2k's ability to localize DLLs to the application and thus load multiple different versions.
Anyway, that's basically a definition of the problem.
BTW, as to your signature line... Linux/BSD is not my main server/workstation and I'm pretty certain I'm far less ignorant than yourself on topics regarding Windows as a result.
I really don't see the point. What Hell is happening on glibc 2.2? As far as I see it is the first glibc that smoothly installs over older versions without cramming the whole system. And not only.
One development/testing system is working here since July 2000. It suffered more than 30 glibc upgrades, ranging from late 2.1 version, running through a whole series of pre-2.2 and right now working on 2.2.1.
During these upgrades, apps suffered some serious crashes during two-three pre-2.2 versions. Not more. Some applications, based on older 2.1 and even 2.0, have kept working until now. For example, Netscape and Quake2. Besides, I didn't note serious problems with 2.1-based apps.
Due to the purpose of this machine, I managed to see how most of these apps are rebuilt up to 2.2 glibc. Here, some incongruences did appear but I cannot say they are a "Hell". Most cases are the result of a few differences in variables. This can be a serious hassle for an average user but it does not hamper his use of a Linux box just by upgrading to 2.2.
Most of the packages I used came from Mandrake Cooker project.
First of all, a free system is not aimed primarily at making binary aplications work, but at making free aplications, which comes with source, work.
Of course binary compatibility is nuice - it means you, or your software vendor, doesn't have to recompile everything now and then. But it comes at a high price - unexpandability. You can not add a field to a datastructure, since that makes the struct bigger, and breaks compatibility. In source, adding a field is never a problem, and compatibility amounts to preserving old fields that someone might expect, and put values that they won't dislike, into these fields.
Of course, you can do uggly tricks like a hash-table of the extra fields for all objects of one type, that you index with the pointer to the original object. This is for example supported in glib. But it's terribly uggly, and is to beg for problems (like mem. management problems).
I agree however that glibc have had some problems - it hasn't allways been 100% source-compatible...
And - try to search for 100% binary compatibility between say Windows 95 and Windows NT 4.0. Have fuN!
--The knowledge that you are an idiot, is what distinguishes you from one.
You are 100% correct. People that have the money to run Oracle (and we are talking about LOTS of money here) go to Oracle and find out what it will run on and go with that. Oracle says RH6.2, then RH6.2 it is. You feel you must be using RH7? Great. Put RH7 on another machine and go play there.
I hate to say this, and hope this isn't considered flamebait, but Linux definitely needs more quality control with PRODUCTION releases of libraries and making sure that if it worked in glibc 2.1, it HAD BETTER work in glibc2.2 too.
If that is impossible, because the library behaved in a buggy (or nonstandard or unsupported or inefficient) way, and fixing it would break something that depended on that feature, that is different than just having something no longer work.
However, old apps need to work with new libraries. Here is a solution. Add a libc call called expect_version(). Your program calls it with the version it expects. The library will behave in a way compatible with that version. If that call is not made, have the library behave at a default level of compatibility . Have binary only software be built to issue this call with the version of all the libraries it is designed to run with.
Just because it CAN be done, doesn't mean it should!
Comment removed based on user account deletion
Static linking is one solution, but it seems a little bit heavy handed. Disk space is one problem, but indeed not major one. Another problem is that the library cannot be shared. This means that two programs using the same library will have to load it in their memory space. This means more memory consumption and more loading time.
Another nice solution could be something like bundles under Mac OS X/Darwin. First the library system knows the version number of each library, and can load the one the application needs - this alone would solve the problem described here. Secondly the library can be installed inside the application's framework, so you have the benefit of static linking without having to build a monolithic program.
This means that you can solve such problems easily. Need a specific library? Move it into the bundle. Can use the normal library? Move it out of the bundle. Simple. The DLL-hell problem comes, IMHO from the rather simplistic dynamic libray handling codesystem.
To have an idea about bundles, have a look at the article in on Ars Technica.
Oracle was originally built for specific operating systems, and in the non Windows arena, specific versions of UNIX. It's not at all surprising that you'd need to run a specific version of Linux from a particular vender in order to use it. Sad but true fact. It really can't be helped at this point so focus on running your organization, not resisting some obvious limitations of the current architecture. (Oracle doesn't work on Debian or Slackware either - my shop tried, and as much as we hated doing it, we were forced to run it on RedHat.)
On another issue... Some people say, "companies should static link libraries to their programs!" Well, this is only taking a bad situation and making it worse. If this is done, binary only releases of software will suffer with flaws in existing versions of whatever system libs they're linked against. Then you have to wait for said company to release a new version whenever the bugs in a system library are fixed. Eventually, we'll manage to do what Windows does, and that is have readily backwards compatable libs that actually work properly.
For now, conform and produce working results.
...or rather, it is only relevant for C++ libraries, the C ABI has been stable for a long time.
So has the glibc ABI actually, except that it is not 100% bug compatible. I.e., applications that relies on bugs in the library in order to work, may break when new the library is updated.
GLibC doesn't do this. Everything's crammed in. And that is bound to make for problems.
IMHO, what GLibC needs to be is a skeleton library with a well-defined API but no innards. The innards would be in seperate, self-contained libraries, elsewhere on the system.
This would mean that upgrading the innards should not impact any application, because the application just sees the exoskeleton, and the API would be well-defined. The addition of new innard components would then -extend- the API, but all existing code would be guaranteed to still work, without relinking against some compat library.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Read the whole message that you responded to and he explains the problem *and* the fix that is possible on Unix type systems. I can have five apps of various vintages that each require a different set of libraries that they linked against.
/usr/$sysname-glibc20-linux/lib/ld-linux.so.2 \ --library-path /usr/$sysname-glibc20-linux/lib \ $netscape $defs $cl_opt "$@" ( real world example )
Like so:
exec
With names like:
libORBit.a
libORBit.la*
libORBit.so@
libORBit.so.0@
libORBit.so.0.5.1*
libORBit.so.0.5.6*
We can keep different versions of files for use, not like the different versions of mfc42.dll that all have the same name. If another version of a library is completely backwards compatible, then a simple symbolic link gives the complete name that the run-time linker is looking for.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
http://sources.redhat.com/glibc/glibc-faq.html
tell your vendor to link it static (using .a libraries instead of .so).
also remind them that a "Linux" version is
meaningless, they should say "Linux/x86" or
"Linux/Alpha" or whatever.
I hate it when a vendor supplies a "Linux" version
that won't work on my hardware, and I can't tell until *after* I've downloaded it.
Getting tired of getting a copy of Oracle for Solaris 2.3, iPlanet for SunOS 4.1.3 and Veritas for Solaris 7 and finding that none of them support my Solaris 8 system. Dammit, what is Sun doing wrong!?
;-) for those who did not guess....
You'd think that you would actually have to pick an OS revision based on the least-common denominator of the supported platforms for your application needs!
Someone needs to go write a Python-based OS and then never change anything. That'll solve it.
...but nobody reads the documentation anymore, so they bring problems on themselves.
Using private interfaces, using static libraries, not using versioning even when shared libraries are in use... I'm not surprised Oracle had problems.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
For instance take Oracle Applications, it is nearly impossible to install it on RedHat 7.0 or any glibc 2.2 based distro since the applications were built against 2.1.x. When you install this software it tries to relink itself with the correct libraries and fails miserably.
If there are substantial glibc 2.1-> 2.2 problems it is really poor coding on the part of the vendors. The use of private (but available) glibc functions was made impossible in the changeover.
There are a few models that will work in this case. First, the older version of glibc can be included with Oracle, and set LD_LIBRARY_PATH or LD_PRELOAD to load those libraries first. Then there is no problem.
Talk to your vendor. Ultimately, if you want to pay to use their software, they have a responsibility to ensure you can use it with some ease.
When using real software like Oracle under linux, you find out what the requirements are for the application you're going to run, and install a compatible setup. You don't just run out to the ftp site, burn a copy of the latest distro of Mandrake, and expect every application you install onto the new system to work flawlessly. Maybe you can run something like apache on every machine everywhere, but Big Important things like Oracle generally have pretty specific system requirements, even under other unicies.
Java, for example, couples libraries and user code much less tightly, yet uses statically type checked interfaces. Java's type checking is actually unnecessarily strict: classes are considered incompatible on dynamic linking even though only some aspects of their implementation changed. ML implementations could easily do the same thing.
Also, the fact that languages like C++ and Java tie inheritance hierarchies to static type checking is an unnecessary and idiosyncratic restriction. You can have perfectly statically type-safe systems that do not have these kinds of inheritance constraints: as long as the compiler and/or linker determines that the aspects of the interfaces you are relying on are type-compatible, it can make the two ends fit together safely, no matter what other changes or additions have happened to the classes. The "signature" extension for GNU C++ did this at compile time, and something similar could be done by the dynamic linker when libraries are loaded.
The efficiency issue is not significant. Even for a completely dynamic object system like Objective-C, a good runtime will have hardly more overhead for a dynamic method call than a regular function call. Any of the systems based on static type checking I mentioned above would do even better. And Java, of course, can actually do better than C/C++ when it comes to libraries because the Java runtime can (and does) inline library code as native code at load/execution time.
Of course, sometimes, things just have to change incompatibly. But as far as I can tell, almost none of the changes in glibc (or most other C/C++ libraries I use regularly) should affect any user code. Almost any kind of library interface would be less problematic than what exists right now.
So, I agree: statically typed languages will not go away. But "DLL hell" is avoidable whether you use statically or dynamically typed languages. In fact, as I mentioned, you could even make it go away in C/C++ by introducing a special library calling convention that has a bit more information available at load time. However, why beat a dead horse?
I work for a company building a network montioring system available for FreeBSD, NT (and 2K), and both RedHat and Debian Linux. We're adding platforms as people request them.
:)
Really, RedHat 7.0 includes the libraries that shipped with 6.2, so while we only support RedHat 6.2 we still work out-of-the-box on RedHat 7.0. Why not use the compatibility libraries ? That's what they're there for - they're not performing worse or anything, they are just older versions of the library.
On UNIX-like systems you actually have VERSIONING on your system libraries. So you can have a perfectly running system with ten different versions of the C library, and each application will use the version it requires.
You're welcome to check out our beta-versions available from sysorb.com, if you don't believe me
First off, If you get anything out of this post it is this: DO NOT RUN A REDHAT X.0 RELEASE IF YOU DON'T UNDERSTAND LIBRARY VERSIONING
NO SUCH THING AS "GLIBC HELL"
There is _no_such_thing_ as "glibc Hell". UNIX (including Linux) has versioning on libraries -- right down tot he filename. _Unlike_ Windows, you can have _multiple_library_versions_ installed. Even Microsoft still has NOT addressed this (and I run into it daily) simply by versioning filenames of libraries. This is a _farce_ and the result of people not understanding the OS in front of them.
UNIX v. WINDOWS ON SYSTEM LIBRARIES
So, in a nutshell, you can have your library issues two ways:
- Recompile for new libraries (if you have source)
Otherwise, no option if you don't have source -- total SOL!Especially on Win2K which makes some libraries untouchable (and quite incompatible with a lot of existing software).
Microsoft does this for "stability", but it is a library- ignorant way of NOT addressing the _real_ issue, lib versioning.
LIBRARY VERSIONING AND SYMBOLIC LINKS
The main reason Windows cannot have UNIX-like library versioning and versioning on filenames is because it lacks symbolic links. With symbolic links, you can have multiple subrevision of a library, with one subrevision the "default" revision, with that (or another) the default "main" version. E.g.,:
libmy.so -> libmy.so.1
libmy.so.1 -> libmy.so.1.1
libmy.so.1.0 -> libmy.so.1.0.7
libmy.so.1.0.7
libmy.so.1.1 -> libmy.so.1.1.3
libmy.so.1.1.2
libmy.so.1.1.3
libmy.so.3 -> libmy.so.3.0
libmy.so.3.0 -> libmy.so.3.0.1
libmy.so.3.0.1
In the preceding example, there are actually only 4 library versions: 1.0.7, 1.1.2, 1.1.3 and 3.0.1. We could easily introduce more versions if programs required them. Most libraries are "parent revisioned" (I don't know what the "official term" is, but that's what I'll call it), so the latest "x.y.z" "version.revision.subrevision" is synlinked as "x.y" "version.revision" as well as "x" "version". As far as compatility between versions, anything goes (and is a per-library consideration), but the "general rule" is as follows:
Most OSS projects, including GLibC, have good versioning schemes that change subrevisions (the "Z" in x.y.z when updates, bugfixes, or non-structural changes are made -- meaning 1.1.2 and 1.1.3 are most likely header/function compatible. So, depending on the library, most programs are fine when linking against X.Y instead of x.y.z-- and do so to keep from requiring the user to have numerous differnet libraries installed. A simple x.y symlink to the latest x.y.z (latest being the max(Z)) is usually all it takes. Again, a "parent revision" symlink does the job.
Now different revisions (the "Y" in x.y.z) usually involve some header/function changes that _may_ be INcompatible. As such vendors usually do not link against just the major version (the "X" in x.y.z) for that reason. E.g., some programs work fine on any GLibC 2.y.z system (BTW, GLibC 2 is aka LibC 6), but most are tied to GLibC 2.0.z (RedHat 5.x), GLibC 2.1.z (RedHat 6.x) or GLibC 2.2.z (RedHat 7.x). Major version changes (again, the "X" in x.y.z) are left for radical, completely incompatible changes -- like LibC 4 (RedHat 3.x), LibC 5 (RedHat 4.x) and GLibC 2 (RedHat 5.x+ -- which caused a bigger stir than 7.0 awhile back ;-PPP).
DON'T RUN A REDHAT X.0 RELEASE UNLESS YOU KNOW WHAT YOU ARE DOING!
98% of the "bitching and moaning" about RedHat 7.0 comes from user naivity on library versioning. Yes, I _do_agree_ that RedHat did release 7.0 too earlier with unfinished components, but since patching GLibC and GCC through December, RedHat 7.0 is a _solid_ release. Never, never adopt a RedHat X.0 release unless you are a seasoned Linux user! Please get the word out on that (although the RedHat 7.0 README on CD 1 *DOES* stress that point too!!!)
[ Side note: The kernel is another matter though -- but understand RedHat cannot "time" the release of GLibC, GCC and the kernel since they are all independent development teams. ]
RedHat gives you _full_warning_ of the all-important GLibC change in a new release. It's always been RedHat's model -- introduce a new, and possibly INcompatible GLibC on a X.0 release. All revisions in a major release have the same GLibC and GCC, and are quite interchangable. I've said it before and I'll say it again, only RedHat seems to do this (although I haven't checked out Debian yet). So I know that going from 6.2 to 7.0 means issues, just like 4.2 to 5.0 did for me almost a half-decade ago. NOTHING NEW!
So, again, if you do NOT know what you are doing, stick with RedHat X.2 releases (or at least X.1)!!! At X.0 releases, most of the Linux world has NOT yet adopted the new GLibC versions -- hence the wealth of binary library incompatibilities. So if you are not familiar with how to deal with them, do NOT try to deal with a RedHat X.0 release!
REDHAT MAINTAINS LIBRARY COMPATIBILITY
Today's RedHat 7.0 (GLibC 2.2) release comes with full RedHat 6.x (GLibC 2.1) compat libs, even a compat devel libs and a compat compiler/linker. And you can also install compat libs from the RedHat 6.2 release for 4.x (LibC 5) and 5.x (GLibC 2.0) compatibility.
[ Side note: I *DO* have a "complaint" with RedHat for not including LibC5 and GLibC2.0 compatibility libraries with RedHat 7.0. And I've let Alan Cox know about them. They should _at_least_ be available on the Powertools CD. I know LibC4 shouldn't be included for security reasons, but LibC5 and, especially, GLibC2.0 should be! ]
ANY LIBRARY ISSUES ARE ALMOST ALWAYS THE PACKAGERS FAULT!
Now that we have the user out of the way, as long as a vendor/packager dynamically links against the specific library version, the binary will use that version. Too many vendors are used to just linking against what they have, especially if it is an older library on their development system. So when a user has a new version of the library, possible with function name, parameter and other structrual changes, core dumps will occur.
If a developer is really worried, there is always the option of statically linking -- i.e. putting the library in the binary itself (so no external library references/dependencies). Of course, there could be licensing issues with GPL or other OSS code to/from commerical and vice-versa. If people think this is limited to Linux, they are _gravely_mistaken_ as most commercial IDE and development tools introduce their own issues. Under Windows, where only one system library can be installed (and that library may be "fixed" in Win2K), you're in for a world of hurt trying to sort them out.
END-USER LIBRARY VERSION ADMINISTRATION
As previously discussed, symlinks are often used to "parent revision" a full "x.y.z" "version.revision.subrevision". Most of the time, RPMS and tarballs/makes installs do this for you. But sometimes, you'll have to administer and create them yourself. Again, doing this is usually easy (it's just a symlink -- "ln -s ") and the first thing to try when a program cannot find a library (e.g., libmy-2.0) where a library exists with a more complete version (e.g., libmy-2.0.1).
-- Bryan "TheBS" Smith
-- Bryan "TheBS" Smith
Independent Author, Consultant and Trainer
You have some interesting viewpoints, but I think you're avoiding the question rather than dealing with it.
In the programming language research community, the feeling is that dynamic languages are very good for things like scripting and prototyping, but are not as good an idea for large software systems.
The problem is twofold - first, as you mention, dynamic languages always get a performance hit. But the second reason - which you miss - might be more important - fewer errors can be detected at compile time... they would only turn up at runtime, or worse, end up as hard to detect bugs. Moreover, the runtime may fail in someplace other than where the error occured. For example, let's say you have a bunch of "polygon" objects in a linked list, and you mistakenly put a "circle" object in that list as well. Much later, you're traversing the list and expect to find a polygons, but instead you find a circle. Type error! But the real error was where you put the circle in the linked list. In a dynamically typed language, you'd have to look to see where the circle was inserted - and the bigger the software system, the harder that becomes. However, in a statically typed language, the compiler tells you right away "hey buddy, you're putting a circle in to polygon list. Fix that, or you don't get object code!".
I don't think that statically typed languages are going to go away. As it often is with issues with software development, the real problem is psychological rather than technological. If backwards compatibility across ".x" releases was a priority for the glibc team, perhaps we wouldn't have this problem. As it is, they are probably more driven to adding new features or fixing really bad old problems in ways which break compatibility... if there are people willing to work on the project who have different goals perhaps it may be time to fork libc again?
However, they offer clear conditions. First, they don't guarentee upwards-compatibility, that is code compiled against glibc 2.2 working with 2.1. Second, C++ is currently off limits (which will change with gcc 3.0). Third, it applies only to shared versions of the library. Fourth, private internal interfaces are off limits.
The Oracle problem is simple: they're using static libraries (ie, ar archives of object files). This doesn't work because symbol versioning (the magic that enables compatibility in shared libraries) isn't implemented for object files. HJ Lu has a page on this issue and possible resolutions.
90% of other compatibility problems result from using private interfaces. This happened to Star Office a while back.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Are there alternatives? Plenty, actually:
You could probably invent a new calling convention for C together with some changes to the dynamic linker that would address this problem for C libraries. While you are at it, you should probably also define a new ABI for C++, something that avoids "vtbl hell" using an approach to method invocation similar to Objective-C. These new calling conventions would be optional, so that you can pick one or the other, depending on whether you are calling within the same module or between different modules. Perhaps that's worth it given how much C/C++ code is out there, but it sure would be a lot of work to try and retrofit those languages. Why not use one of the dozens of languages that fix not just this problem but others as well?
A related approach is to still write a lot of stuff in C/C++ but wrap it up in a dynamic language and handle most of the library interactions through that. That was the dream of Tcl/Tk (too bad that the language itself had some limitations).
Altogether, I think the time to fix this in C/C++ has passed, and COM-like approaches didn't work out. My recommendation would be: write your code in a language that suffers less from these problems, Python and Java are my preference, and add C/C++ code to those when needed for efficiency or system calls.