Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
=?iso-8859-15?q?Fran=E7ois?= Pons [EMAIL PROTECTED] wrote: Raul Dias [EMAIL PROTECTED] writes: the linker will match them together ? This sounds me a bug in the dynamic linker ? Not in the linker itself, the reason was that the main package and the library were compiled with different (and c++ ABI incompatible) GCCs. This means when you load one libstdc++-.so.yyy, any other library libstdc++-.so.YYY will not be loaded or chached. It probably will. It will segfaults then. e.g. running a kde application compiled with gcc 3.0 and kdelibs compiles with gcc 2.96. []'s Raul Dias
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
Raul Dias [EMAIL PROTECTED] writes: =?iso-8859-15?q?Fran=E7ois?= Pons [EMAIL PROTECTED] wrote: Raul Dias [EMAIL PROTECTED] writes: But what do you want exactly, to keep gcc-2.95.3-19cl.src.rpm instead of a newer gcc which provides the same libstdc++-libc6.2-2.so.3 ? No. A newer gcc would install a different libstdc++ (different soname). This is exactly what we want. What I am suggesting is a way to let urpmi detect when a c++ application package will not work before installing them. How can we detect such behaviour ? 1- check if the install candidate package depends on libstdc++ 2- if it does, save the libstdc++ so name, 3- Verify each other Requires this package has (probably only lib requirements). 4- Check each package that provides what this package require to see if they also depends on libstdc++ 5- If they do, check if they depend on the same libstdc++ as the install candidate package (step 2). 6- If they are different abort (it will break, different gccs used) 7- If they are the same install the package Ok, I try to understand what you want, so if a library requires a different version of the main application requires on the same library, the linker will match them together ? This sounds me a bug in the dynamic linker ? It should use a separate environment for the library and not use the same as the other one. Anybody else confirms this ? Gwenole ? Fred ? François.
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
=?iso-8859-15?q?Fran=E7ois?= Pons [EMAIL PROTECTED] wrote: Raul Dias [EMAIL PROTECTED] writes: =?iso-8859-15?q?Fran=E7ois?= Pons [EMAIL PROTECTED] wrote: Raul Dias [EMAIL PROTECTED] writes: But what do you want exactly, to keep gcc-2.95.3-19cl.src.rpm instead of a newer gcc which provides the same libstdc++-libc6.2-2.so.3 ? No. A newer gcc would install a different libstdc++ (different soname). This is exactly what we want. What I am suggesting is a way to let urpmi detect when a c++ application package will not work before installing them. How can we detect such behaviour ? 1- check if the install candidate package depends on libstdc++ 2- if it does, save the libstdc++ so name, 3- Verify each other Requires this package has (probably only lib requirements). 4- Check each package that provides what this package require to see if they also depends on libstdc++ 5- If they do, check if they depend on the same libstdc++ as the install candidate package (step 2). 6- If they are different abort (it will break, different gccs used) 7- If they are the same install the package Hi, Ok, I try to understand what you want, sorry if I am not too cllear. so if a library requires a different version of the main application requires on the same library, ...and the main package requires this library,... the linker will match them together ? This sounds me a bug in the dynamic linker ? Not in the linker itself, the reason was that the main package and the library were compiled with different (and c++ ABI incompatible) GCCs. It should use a separate environment for the library and not use the same as the other one. Anybody else confirms this ? Gwenole ? Fred ? François. Raul Dias
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
Raul Dias [EMAIL PROTECTED] writes: the linker will match them together ? This sounds me a bug in the dynamic linker ? Not in the linker itself, the reason was that the main package and the library were compiled with different (and c++ ABI incompatible) GCCs. This means when you load one libstdc++-.so.yyy, any other library libstdc++-.so.YYY will not be loaded or chached. François.
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
On Thu, 7 Mar 2002, Raul Dias wrote: the linker will match them together ? This sounds me a bug in the dynamic linker ? Not in the linker itself, the reason was that the main package and the library were compiled with different (and c++ ABI incompatible) GCCs. 1) Could you please name me such a package in Mandrake Linux 8.2? 2) You can't have a main package was built with another library with incompatible ABI at least for gcc2 - gcc3 interop since the linker would have cried when linking that said package, so you won't get that package. You can however have program X built with library L1, both with gcc2. Then, you can have L2, same than L1 but built with gcc3. Say both L1 and L2 have the same soname. It's clear that if you try to run X with L2 you are likely to run into a relocation error. That's normal. The user knows which of L1 or L2 program X was built so he will have installed the right library. Bye, Gwenole.
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
Gwenole Beauchesne [EMAIL PROTECTED] wrote: On Thu, 7 Mar 2002, Raul Dias wrote: the linker will match them together ? This sounds me a bug in the dynamic linker ? Not in the linker itself, the reason was that the main package and the library were compiled with different (and c++ ABI incompatible) GCCs. 1) Could you please name me such a package in Mandrake Linux 8.2? There is no such package AFAIK. however there will be user's package as people start to use gcc 3.x instead of 2.96 as this was the issue in the beggining of this thread. 2) You can't have a main package was built with another library with incompatible ABI at least for gcc2 - gcc3 interop since the linker would have cried when linking that said package, so you won't get that package. True. However rpm would allow such a package to be installed. The whole point was to suggest to add this as a feature to urpmi avoiding this to happen. just trying to help the description of the urpmi package be true ;) Best Regards, Raul Dias
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
Raul Dias [EMAIL PROTECTED] writes: I have proposed a new kind of conflict checking for rpm, but JBJ is not sure (yet) if rpm is the right place for it. However URPMI would be a right tool to check for it. The problem: Using a C++ application compiling with one gcc that depends on another C++ library that was compiled with another gcc will __not__ work and probably segfaults. This is the main issue discussed in this thread. :) How do we know if a package is a c++ application/lib? \ It will depends on libstdc++.so.X How do we know what gcc was use to compile a c++ package? the in the libstdc++.so. dependency is different to every gcc version/c++ ABI. This also means that when the time comes and we get a final ABI, new gccs will keep the same soname in the libstc++ lib. How can urpmi know that a c++ package will not work in the system __even__ if the dependencies are met? If a c++ package will be installed in the system, urpmi should check for every package that provides its dependencies to see if they also depends on a libstdc++. If the libstdc++ which they depends are different, the package should not be installed. Any thought about this? Hum, urpmi use rpm dependencies, which use effectively so name, so name should be changed if compatibility is broken. $ rpm -qR xalan-c | grep libstdc libstdc++-libc6.2-2.so.3 $ ldd /usr/bin/testXPath | grep libstdc libstdc++-libc6.2-2.so.3 = /usr/lib/libstdc++-libc6.2-2.so.3 (0x4083d000) $ objdump -x /usr/lib/libstdc++-libc6.2-2.so.3 | grep SONAME SONAME libstdc++-libc6.2-2.so.3 How can we known more here ? François.
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
=?iso-8859-15?q?Fran=E7ois?= Pons [EMAIL PROTECTED] wrote:
Raul Dias [EMAIL PROTECTED] writes:
The problem:
Using a C++ application compiling with one gcc that depends on
another C++ library that was compiled with another gcc will
__not__ work and probably segfaults.
This is the main issue discussed in this thread. :)
How do we know if a package is a c++ application/lib?
\
It will depends on libstdc++.so.X
How do we know what gcc was use to compile a c++ package?
the in the libstdc++.so. dependency is different
to every gcc version/c++ ABI.
This also means that when the time comes and we get a final
ABI, new gccs will keep the same soname in the libstc++ lib.
How can urpmi know that a c++ package will not work in
the system __even__ if the dependencies are met?
If a c++ package will be installed in the system, urpmi
should check for every package that provides its dependencies
to see if they also depends on a libstdc++.
If the libstdc++ which they depends are different, the package
should not be installed.
Any thought about this?
Hum, urpmi use rpm dependencies, which use effectively so name, so name should
be changed if compatibility is broken.
And it is. every incompatible ABI in gcc has a soname changed.
So, this is what can be used to track the issue down
$ rpm -qR xalan-c | grep libstdc
libstdc++-libc6.2-2.so.3
$ ldd /usr/bin/testXPath | grep libstdc
libstdc++-libc6.2-2.so.3 = /usr/lib/libstdc++-libc6.2-2.so.3 (0x4083d000)
$ objdump -x /usr/lib/libstdc++-libc6.2-2.so.3 | grep SONAME
SONAME libstdc++-libc6.2-2.so.3
How can we known more here ?
I will use qt2 as an example:
$ rpm -qR qt2 | grep libstd
libstdc++-libc6.2-2.so.3
$ rpm -q --whatprovides $(rpm -qR qt2 | grep libstd)
libstdc++-2.95.3-19cl
and of course, if you want to know which gcc generated this (not really needed):
$ rpm -q $(rpm -q --whatprovides $(rpm -qR qt2 | grep libstd) ) --qf %{SOURCERPM}\n
gcc-2.95.3-19cl.src.rpm
Btw, I did this on a CL system, not mdk. But the results should be equivalent.
Regards,
Raul Dias
François.
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
Raul Dias [EMAIL PROTECTED] writes:
$ rpm -qR xalan-c | grep libstdc
libstdc++-libc6.2-2.so.3
$ ldd /usr/bin/testXPath | grep libstdc
libstdc++-libc6.2-2.so.3 = /usr/lib/libstdc++-libc6.2-2.so.3 (0x4083d000)
$ objdump -x /usr/lib/libstdc++-libc6.2-2.so.3 | grep SONAME
SONAME libstdc++-libc6.2-2.so.3
How can we known more here ?
I will use qt2 as an example:
$ rpm -qR qt2 | grep libstd
libstdc++-libc6.2-2.so.3
$ rpm -q --whatprovides $(rpm -qR qt2 | grep libstd)
libstdc++-2.95.3-19cl
and of course, if you want to know which gcc generated this (not really needed):
$ rpm -q $(rpm -q --whatprovides $(rpm -qR qt2 | grep libstd) ) --qf %{SOURCERPM}\n
gcc-2.95.3-19cl.src.rpm
Btw, I did this on a CL system, not mdk. But the results should be equivalent.
But what do you want exactly, to keep gcc-2.95.3-19cl.src.rpm instead of a newer
gcc which provides the same libstdc++-libc6.2-2.so.3 ?
If this is not running because of incompatible library used, the so name should
be changed ? no ?
François.
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
=?iso-8859-15?q?Fran=E7ois?= Pons [EMAIL PROTECTED] wrote:
Raul Dias [EMAIL PROTECTED] writes:
$ rpm -qR xalan-c | grep libstdc
libstdc++-libc6.2-2.so.3
$ ldd /usr/bin/testXPath | grep libstdc
libstdc++-libc6.2-2.so.3 = /usr/lib/libstdc++-libc6.2-2.so.3 (0x4083d000)
$ objdump -x /usr/lib/libstdc++-libc6.2-2.so.3 | grep SONAME
SONAME libstdc++-libc6.2-2.so.3
How can we known more here ?
I will use qt2 as an example:
$ rpm -qR qt2 | grep libstd
libstdc++-libc6.2-2.so.3
$ rpm -q --whatprovides $(rpm -qR qt2 | grep libstd)
libstdc++-2.95.3-19cl
and of course, if you want to know which gcc generated this (not really needed):
$ rpm -q $(rpm -q --whatprovides $(rpm -qR qt2 | grep libstd) ) --qf
%{SOURCERPM}\n
gcc-2.95.3-19cl.src.rpm
Btw, I did this on a CL system, not mdk. But the results should be equivalent.
But what do you want exactly, to keep gcc-2.95.3-19cl.src.rpm instead of a newer
gcc which provides the same libstdc++-libc6.2-2.so.3 ?
No. A newer gcc would install a different libstdc++ (different soname).
What I am suggesting is a way to let urpmi detect when a c++ application package
will not work before installing them.
If this is not running because of incompatible library used, the so name should
be changed ? no ?
Yes, and it is changed.
- Raul Dias
Re: c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
Raul Dias [EMAIL PROTECTED] writes: But what do you want exactly, to keep gcc-2.95.3-19cl.src.rpm instead of a newer gcc which provides the same libstdc++-libc6.2-2.so.3 ? No. A newer gcc would install a different libstdc++ (different soname). This is exactly what we want. What I am suggesting is a way to let urpmi detect when a c++ application package will not work before installing them. How can we detect such behaviour ? François.
