Tom Schneider wrote:
Here is your problem: GPC can not be used with different version of GCC. If it's compiled from sources against of GCC 2.8.1 you need GCC 2.8.1 to run the beast, if it's compiled against of EGCS 1.1.2 you need EGCS 1.1.2 and so on. Even minor changes (EGCS 1.1.1 => EGCS 1.1.2) will break harmony :-)
That's lovely. So why not read from the current gcc what version it is and if they differ put up a BIG MESSAGE and abort?
The current problem is a bit different: GPC searches for the GCC files (including libgcc.a and cc1, the actual C compiler which is used for compiling C files referenced from Pascal code) in the same directory it's installed in (i.e. <prefix>/lib/gcc-lib/<platform>/<version>/). If there is a matching GCC version, it will be installed in the same directory, GPC will find the files, and everything is fine.
If there's no matching GCC installed, GPC will simply not see it, and will therefore not give any particular message about this situation, just the usual linker error that a library is not found.
Well, I'm currently writing a utility to simplify the usage of GPC, avoid the automake problems, and I've also intended it to simplify the calling of GCC so it will by default call `gcc' rather than cc1 (with special handling for cross-compiles and similar things) which will work with any installed GCC (as long as it can be found in the PATH). Now I'm reading this stuff about libgcc.a incompatibilites, and I'm wondering if that's the right thing to do, or if it will just replace an obvious problem by more difficult to find subtle problems (which would be a bad thing)...
Khimenko Victor wrote:
20-Dec-99 18:11 you wrote:
Hello again.
Khimenko Victor wrote:
to a global one (such as /usr/local/lib/). After my humble experience, this doesn't harm. (But don't blame me if it does for you.;-)
It will work for simple programs like "Hello, World!" (where libgcc is not needed anyway) just fine. But for more complex programs it'll create problems. libgcc.a is INTERNAL gcc library - [...]
So you mean that different versions of `libgcc.a' are not compatible enough even between egcs-1.1.1 and egcs-1.1.2 to make this work in a stable way?
It CAN be compatible but it's NOT tested (and since it's not used this way and not used much overral probability is VERY high to get silent damage and not notice it for very long time).
Well, then the creator of the GPC binary distribution _must_ supply a matching `libgcc.a'.
He just must add -- cut -- Require: gcc = 2.8.1 -- cut -- line in .spec file. Then rpm will just refuse to install gpc without corresponding gcc.
If the incompatibility really exists, than that's indeed what has to be done, i.e. each GPC binary should require or include GCC. Just supplying libgcc.a with GPC without the corresponding GCC would be problematic because:
- Parts of the Run Time System and some units are written in C, and would "require" another libgcc.a if compiled with another C compiler.
- Perhaps it's a problem for the packages if both GCC and GPC contain libgcc.a. I don't know the different packaging systems to well, so I don't know if they're designed to handle this situation.
But I'm still wondering about this incompatibility. I recently did a joint Pascal/C++ project using gpc-19990813, based on gcc-2.8.1, and g++-2.95, linking to g++-2.95's libgcc.a, and it works well under both Solaris/Sparc and Linux/x86, even though the Pascal code does some 64 bit arithmetic...
That's, of course, no proof that there are no problems. But what about libraries, e.g.? If they're dependent on the libgcc.a used for compiling them, this would mean that each program using a library has to be compiled with the same compiler version (i.e., the same libgcc.a version) as the library itself, to prevent subtle bugs. IOW, after upgrading a compiler, one would have to recompile libc and everything that depends on it, i.e. basically the whole system. I've never heard of this, and I really hope this isn't true...
Frank