[gentoo-dev] revdep-rebuild
Hi, I have finally had enough of how slow it is compared to for example the "prelink -amR" command which does about the same task in terms of difficulty! So I have started making a small C program which does the "Checking dynamic linking consistency..." part of the revdep-rebuild program (I think this the the most time intensive part). This program can then be called by the script. So far all I see the program needing to do is read /root/.revdep-rebuild.1_files and use /root/.revdep-rebuild.2_ldpath as the LD_LIBRARY_PATH and write any bad files to /root/.revdep-rebuild.3_rebuild Any other LD_?? env variables I would need to consider? Also anyone have any opinions or caveats I should take into account? Thanks, Stefan -- Stefan Jones <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
On Sat, 2005-08-13 at 23:26 -0400, Mike Frysinger wrote: > i've already contacted fuzzray about utilizing two packages solar put > together > (and can be found in portage already): > pax-utils: scanelf > portage-utils: qfile Thanks for the ideas. I had a quick look at the programs; qfile: This would be useful in cleaning up the the last part of finding which package the file belongs to. But that part is already fairly quick compared to the rest. scanelf: >From what I can see scanelf can print what libraries a file needs but it cannot say if the libraries are present. For example: /usr/bin/scanelf /bin/ls -n TYPE NEEDED FILE ET_EXEC librt.so.1,libncurses.so.5,libc.so.6 /bin/ls So you would need to keep a list of all libraries to check against. Thus I prefer using: LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 /bin/ls But you could use "ldconfig -p" to gain a list of all the libraries, put them in a hash table and then use scanelf. All seems good, Stefan -- Stefan Jones <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
On Sun, 2005-08-14 at 09:52 -0500, Paul Varner wrote: > > Please don't. FreeBSD's ldconfig is *not* the same and this would mean > > breaking (again) revdep-rebuild on Gentoo/FreeBSD. > > > Some of those solutions are definitely not portable. > Well all we really need is the same utility to work across platforms, different platforms could have different implementations for certain functions. This has to be so if we are every going to have reasonable performance. But FreeBSD must have an equivalent function for it's dynamic linker to "ldconfig -p", if not some code could be written up to do it. fuzzyray: Want me to do anything useful in particular? Had a quick look at Bug 63643. From what I can see that is a different problem then what revdep-rebuild solves (missing shared libraries), as you said. I think it can be best described as changing API between minor revisions of libraries. Will think a bit more. Stefan -- Stefan Jones <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
Stefan Jones wrote: So I have started making a small C program which does the "Checking dynamic linking consistency..." part of the revdep-rebuild program (I think this the the most time intensive part). This program can then be called by the script. So far all I see the program needing to do is read /root/.revdep-rebuild.1_files and use /root/.revdep-rebuild.2_ldpath as the LD_LIBRARY_PATH and write any bad files to /root/.revdep-rebuild.3_rebuild I have finished doing the above for linux/glibc, it can be found at http://dev.gentoo.org/~cretin/revdep-rebuild.tar.bz2 I just made a small C-program to check the dependencies, it uses ld-linux.so.2 check if the file is an ELF and then to check if it's libraries are present. For other archs you can use present system or do something else, the original revdep-rebuild script is still used, just a bit is cut out and uses the binary instead, so other archs can use the old code easily. The speed up is quite noticeable: ( see results.txt in the tarball ) Now we have: real0m46.803s user0m4.544s sys 0m41.075s Instead of: real8m12.674s user0m20.569s sys 7m41.593s for revdep-rebuild --keep-temp -i -- -p Anyway, this is really proof of concept only, can do another version using scanelf using a list from another source of all available system libraries (ldconfig -p on linux) Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
On Mon, 2005-08-15 at 17:18 +0900, Georgi Georgiev wrote: > On x86-64 the native ELFs do not use ld-linux.so.2, but > ld-linux-x86-64.so.2 instead. Okey, thanks, using /usr/include/gnu/lib-names.h would soon sort out that problem at compile time! Stefan -- Stefan Jones <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
On Mon, 2005-08-15 at 23:35 +0900, Georgi Georgiev wrote: > I hope you do intend to support both types of executables on amd64. > After all the current method with ldd works fine for both and I guess > you don't want any regression. A quick look at /usr/bin/ldd shows that is just goes though using both dynamic linkers and sees which one works. This could be done for amd64 I suppose. But first I have an idea to only use scanelf (but that may have issues with 32/64 combined userspaces) which I would want to implement. -- Stefan Jones <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
On Mon, 2005-08-15 at 15:57 -0400, Mike Frysinger wrote: > > > > But first I have an idea to only use scanelf (but that may have issues > > with 32/64 combined userspaces) which I would want to implement. > > no, it doesnt ... scanelf can handle any ELF format regardless of > endian/bitsize of the host or target or any combo thereof > > you can scan 32bit MSB ARM ELF's from a host 64bit LSB X86_64 host just as > easily as say from a 32bit MSB PARISC host Sorry, was not clear enough, a 32bit library cannot resolve a 64bit dependency. So when you read in the available libraries and there dependencies you need to keep track of which type they are. Anyway, the -i flag to scanelf fixes that and other issues, just group all the data from scanelf by interpreter (so have multiple hashes, one for each interp). Stefan -- Stefan Jones <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GNOME 2.12.0 Final - Testing
Phil Richards wrote: | ~ # emerge -puv --newuse gnome | | These are the packages that I would merge, in order: | | Calculating dependencies \ | !!! All ebuilds that could satisfy "sys-apps/pmount" have been masked. | !!! One of the following masked packages is required to complete your request: | - sys-apps/pmount-0.9.3-r3 (masked by: package.mask) | # Doug Goldstein <[EMAIL PROTECTED]> (7 Sep 2005) | # Remasking because the Gnome herd is too lazy to look | # into bugs that are over 4 months old with regards to | # hal and dbus. Patches provided and everything. | # When I volunteered to fix it and handle any issues.. | # I received the stock "wait for foser" response. Normally, I would just unmask pmount, but the comment doesn't exactly fill me with confidence as regards the stability of pmount (and whereas I am happy for gnome to crash in a heap, I tend to be a little more cautious around things that work at lower levels in the system)... Should I just go ahead and unmask, or what if I want to test out gnome 2.12? Unmask pmount, it is needed now to get useful hal support where you can mount USB drives from nautilus when they are hot plugged. This is because with the new hal they have removed the fstab updater. ( or you could just put -hal in your USE flags, but better just unmasking it and finding the bugs - I have not found any ) Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Hi all, I am just wondering about people's option about making a new category, called something like dev-xmingw or similar. At the moment we have in portage: dev-util/xmingw-binutils dev-util/xmingw-runtime dev-util/xmingw-gcc dev-util/xmingw-w32api Which gives a usable W32 toolchain on gentoo using just standard W32 libraries. But every so often people submit ebuild for other libraries for use with this toolchain ( eg. http://bugs.gentoo.org/show_bug.cgi?id=101468 ) I have not added them up to now as it would, in my opinion, just clutter things. The other option is to make an external non-official tree that people could use as an overlay. Opinions? Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Mike Frysinger wrote: On Thursday 13 October 2005 12:25 pm, Stefan Jones wrote: dev-util/xmingw-binutils dev-util/xmingw-runtime dev-util/xmingw-gcc dev-util/xmingw-w32api i'd prefer to see these moved into the normal binutils/gcc ebuilds myself I do not think that would ever work well; the bootstrap method is a bit to out of sync with the GNU/Linux target Plus it would mean I would step on the gcc maintainers toes alot. [ xmingw cross compiled libraries] are these libraries special ? that is, are these things specific to xmingw ? or are they just ebuilds which take normal packages and force them to be compiled with the xmingw toolchain ? About half (guess) are xmingw spercific; will not compile in GNU/Linux. Others are normal libraries which work on Linux but need special tricks to get working with the crosscompiler. if they are xmingw-specific, then they should be added to the tree as sep packages, but if they are normal packages and these ebuilds are special hacks to cross compile them with xmingw, then they have no business in the tree But what is the difference in effect? Both are libraries for the xmingw toolchain, but a line would need to be drawn otherwise I might as well port the entire cygwin distribution! Out of tree collection looks good; but I doubt anyone will find it and I do not really use xmingw! Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Mike Frysinger wrote: glanced in the ebuilds and they dont look too bad to me ... this is how we do avr after all ... we punted the avr gcc/binutils ebuilds and now people have to `emerge crossdev && crossdev avr` Ok, many thanks Mike for the input. I guess I better get on with it! Stefan -- gentoo-dev@gentoo.org mailing list
