[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
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] 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
[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
