[Cooker] [Fwd: [CHRPM] drakxtools-9.2-0.15mdk]
Hi, Is there an official page for drakxtools? >--=-=-= >Name: drakxtools Relocations: (not relocateable) >Version : 9.2 Vendor: MandrakeSoft >Release : 0.15mdk Build Date: Tue Jul 15 20:30:41 2003 >Install date: (not installed) Build Host: ke.mandrakesoft.com >Group : System/Configuration/OtherSource RPM: (none) >Size: 6342240 License: GPL >Packager: Thierry Vignaud <[EMAIL PROTECTED]> >URL : http://www.mandrakelinux.com/en/drakx.php2 This URL does not exist and the one with php3 in the end is for the DrakX (installer) project. []'s Raul Dias
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
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
=?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: [Cooker] Possible packaging bug with many packages?
Hi, IpSo <[EMAIL PROTECTED]> wrote: >I've been using APT-GET with cooker since the beginning of the year, and its >worked exceptionally well up until now. When I run APT-GET UPDATE I get the >follow errors: > >WARNING: 'pilot-link' has 2 packages with same version but different >dependencies. That usually means a packaging bug. Not an error, a warning ;) > >That error repeats itself 186 times with the following packages: [...] some warnings. > >I've tried this on two different computers, using rpmfind.net and sunsite.uio.no >as sources. I assume this has been done intentionally? Are there any official or >unofficial plans to support APT-GET for RPMs? Basicaly this means that somewhere there are packages with the same name, version, epoch and releases but they are not the same. e.g. a recompiled package. I am not too sure, but I thing apt uses md5 to make sure a package is the same, so a recompiled package will have a different md5 and therefore will cause this errors. You either have too many repositories (incompatible ones) in your source.list or you have this packages installed on your system and the ones on the repository are the same name,epoch,version,release, but not the same md5. So, what is on your sources.list? []'s Raul Dias > > >IpSo
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
=?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. >
c++ conflicts with urpmi WAS: Re: [Cooker] Cant compile anything that needs Qt
Gwenole Beauchesne <[EMAIL PROTECTED]> wrote: >On Tue, 5 Mar 2002, pascal wrote: > >> I am not a programmer but a Merchant Navy Officer, by hoby a very small >> tester, but sugest it should be great if somme of you could find some scripte >> or others making transparent capability for compiling applications using QT >> even with gcc 2.96 or gcc 3.0 without turning around the clock > >gcc-2.96 is the system compiler, thus meaning that everything was built >with it and verified to work OK. So coherency here is for a user to build >with the system compiler. gcc-3.0.4 is a toy compiler for 8.2 for people >willing to test it, have other features. This will change for 9.0 as more >testing will be done with gcc3+ compilers. > >You are definetely in trouble if you want to mix gcc3 C++ code with gcc2 >C++ code. Otherwise, C code should be OK. I am not saying that compiling >C++ code with gcc3 doesn't work. It's just that you need to check that all >other dependent C++ libs are built with it too. > >Again, it is always advised to use the system compiler. "2.96" for 8.2. Hi, 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? []'s Raul Dias
Re: [Cooker] Applixware 5.0 segfaults
Gary Chisholm <[EMAIL PROTECTED]> wrote: >Drakers, > >I am having a few issues with cooker and Applixware 5.0, very slow at >loading Applix, sometimes up to 5 minutes. Segfaults when words dialogs >popup 'axmain: signal Segmentation fault'. I think that this is a glibc problem (as with corel draw! and corel wordperfect). Probably the best way to run it would be to create a compat-glibc-2.0 or compat-glibc-2.1 package in somewhere like /usr/i386-glibc-20-linux/ . Then running with with LD_LIBRARY_PATH=/usr/i386-glibc-20-linux/ axmain would do the tricky. I plan to do/try this when I get enough time. []'s Raul Dias
Re: [Cooker] perl-GTK documentation
Guillaume Rousse <[EMAIL PROTECTED]> wrote: >Perl GTK man page refers to Gtk::reference, Gtk::cookbook and Gtk::objects >man pages, but i can't find them anywhere. I had to read drakxtools to learn >perl-GTK :-) >I just found lots of html documentation in libgtkmm1.2-devel, but that was >not obvious. Why not have a perl-GTK-manual package instead ? All documentation I ever found about gtk perl was in the examples codes. Paolo Molaro has set up a site for this some time later. http://www.gtkperl.org []'s Raul Dias