Configure bombs out with "res_query not found". Reproducible: Always Steps to Reproduce: 1.emerge glib Actual Results: fail Expected Results: succeed I have the beginnings of a solution to this, see attachments and text to follow.
Created attachment 214110 [details, diff] A patch (goes in dev-libs/glib/files, ldo)
Created attachment 214111 [details, diff] Patch to ebuild to utilize patch and implement other hacks Not sure if all this is strictly needed -- in particular, some of the includes probably aren't needed. This is just a proof of concept.
(In reply to comment #0) > Configure bombs out with "res_query not found". OK, so glib needs res_query and other dns type stuff that gentoo prefix does not provide. However, the API is available in the suacommunity build of bind. Unfortunately (a) there is no bind in interix prefix and (b) the sources for bind do not seem to be available (Why? I dont know). Porting bind to Interix is clearly a nontrivial task that should not be duplicated unless absolutely neccesary. So what to do? Best solution would be to track down the bind sources and create an ebuild so they can be properly integrated into prefix. I'm not holding my breath on this. As a stopgap measure, an ebuild could be created which installs the suacommunity binaries into prefix. I have not done this yet, although I may get around to it in due time. In the meanwhile, as a proof of concept, I have hacked together the enclosed patches which allow the suacommunity build to be installed in the official suacommunity way into /usr/local and used by this ebuild. I am not sure if the resulting binaries will actually work without adding /usr/local/lib/bind to ${PREFIX}/etc/ld.so.conf. If not, there is probably some linker magic that could be added to the ebuild to make it work without this. But the resulting libraries do seem to work, at least partially, as I am able to do name resolutions using the glib test suite. So here are all the steps to make this work: 1) Make an overlay, add it to ${PREFIX}/etc/make.conf, and clone ${PREFIX}/usr/portage/dev-libs/glib. 2) Add the hack patch to ${OVERLAY}/dev-libs/glib/files and patch the ebuild. Run ebuild digest on the resulting ebuild. 3) Open a standard (non-prefix) interix shell and follow the suacommunity guide to bootstrapping their bsd-ish package tool. 4) Still in the non-prefix shell, run pkg_update -L bind. This will install bind and its dependencies into /usr/local/ 5) Go back into your gentoo prefix environment and just "emerge -u1 glib". It will work, or it does for me at least. Now you can proceed to update all the packages in @world held back due to glib-2.22.2 -- or, at least, to begin debugging them :S
(In reply to comment #3) > OK, so glib needs res_query and other dns type stuff that gentoo prefix does > not provide. However, the API is available in the suacommunity build of bind. I see now that some other ebuilds already do this so I will rework this to follow their (presumably much less ugly) examples.
(In reply to comment #3) > > Now you can proceed to update all the packages in @world held back due to > glib-2.22.2 -- or, at least, to begin debugging them :S > welcome to my world :) haha. (In reply to comment #4) > > I see now that some other ebuilds already do this so I will rework this to > follow their (presumably much less ugly) examples. > huh..? what do you mean? i guess i won't accept any patches that use the closed source libraries from interop - i don't think thats a good idea. the solution i can see is to (as i always did) patch glib, until it does not need res_query anymore. i know that this may cut down functionality in some places, but hey - we're on interix anyway. this is not linux ;) name resolution is working in other interix builds too, so there has to be a good solution to this (not a perfect one, but good is better than nothing!).
i just created a new package in the tree: itx-bind. i still need to test, whether _all_ packages still build and work fine, after adding this lib, since it overlays some of the system headers (ouch). the library is based on the libbind that is delivered with interix (not the one from interop), which is well-hidden on all installations in /usr/local/include/bind (or /usr/local/bind/include, depending on interix version) and /usr/local/lib/bind. glib builds fine with this lib, but ATM i can't yet tell whether things will work :) i'm committing this, and continuing to test, maybe you can try too? (the glib patches are different for interix <= 5.2 and >= 6.0 due to missing ipv6 support in older versions, so a 6.0 build success notice would be helpfull ;)) you'll need a new gtk-doc-am package to successfully eautoreconf, but that is not yet there. i'm talking to the maintainer to get it bumped (should be trivial). in the meantime, a simple "cp gtk-doc-am-1.1{1,3}.ebuild && repoman manifest" should do... :)
(In reply to comment #6) > i just created a new package in the tree: itx-bind. i still need to test, > whether _all_ packages still build and work fine, after adding this lib, since > it overlays some of the system headers (ouch). > the library is based on the libbind that is delivered with interix (not the one > from interop), which is well-hidden on all installations in > /usr/local/include/bind (or /usr/local/bind/include, depending on interix > version) and /usr/local/lib/bind. > glib builds fine with this lib, but ATM i can't yet tell whether things will > work :) i'm committing this, and continuing to test, maybe you can try too? > (the glib patches are different for interix <= 5.2 and >= 6.0 due to missing > ipv6 support in older versions, so a 6.0 build success notice would be helpfull > ;)) > you'll need a new gtk-doc-am package to successfully eautoreconf, but that is > not yet there. i'm talking to the maintainer to get it bumped (should be > trivial). in the meantime, a simple "cp gtk-doc-am-1.1{1,3}.ebuild && repoman > manifest" should do... :) Oh, nifty. I will definitely give this a try. Not sure about gtk-doc-am, I may have it in my overlay. Will report back after I get some hours to mess around with it.
(In reply to comment #7) > (In reply to comment #6) > > i just created a new package in the tree: itx-bind. i still need to test, > > whether _all_ packages still build and work fine, after adding this lib, since > > it overlays some of the system headers (ouch). > > the library is based on the libbind that is delivered with interix (not the one > > from interop), which is well-hidden on all installations in > > /usr/local/include/bind (or /usr/local/bind/include, depending on interix > > version) and /usr/local/lib/bind. > > glib builds fine with this lib, but ATM i can't yet tell whether things will > > work :) i'm committing this, and continuing to test, maybe you can try too? > > (the glib patches are different for interix <= 5.2 and >= 6.0 due to missing > > ipv6 support in older versions, so a 6.0 build success notice would be helpfull > > ;)) > > you'll need a new gtk-doc-am package to successfully eautoreconf, but that is > > not yet there. i'm talking to the maintainer to get it bumped (should be > > trivial). in the meantime, a simple "cp gtk-doc-am-1.1{1,3}.ebuild && repoman > > manifest" should do... :) > Oh, nifty. I will definitely give this a try. Not sure about gtk-doc-am, I > may have it in my overlay. Will report back after I get some hours to mess > around with it. I've been working on this. It doesn't compile out of the box but I'm working on some fixes... should I start a new bug for it?
(In reply to comment #8) [snip] > > I've been working on this. It doesn't compile out of the box but I'm working > on some fixes... should I start a new bug for it? > hm, no, continue here. whats the problem? it worked fine here, but i still only tried on 5.2 :( ...
also i've found out, that installing the itx-bind package breaks the build of some other packages (libX11 for example). not good. i think i'll install it in some subdirs in the prefix, and only point packages to it that are fixed for it... like glib :)
(In reply to comment #9) > > It doesn't compile out of the box > whats the problem? A few easy problems have been solved but the difficult one is that ld segfaults linking libgio. I suspect this has to do with gmodule so for a start, I'm working on patches to just leave gmodule out. Really fixing it will probably prove more challenging.
(In reply to comment #11) [snip] > A few easy problems have been solved but the difficult one is that ld segfaults > linking libgio. I suspect this has to do with gmodule so for a start, I'm > working on patches to just leave gmodule out. Really fixing it will probably > prove more challenging. > owh, damn. could you also please sync? i just moved the itx-bind files into another directory, so they don't case other packages to fail. glib now contains the necessary append-{ld,}flags commands to make it find lib{resolv,bind}... it should not make a difference for glib, but at least others don't fail ... :) hopefully i'll get to building glib on interix6 soonish, as i start updating DVD images this week...
Created attachment 216798 [details, diff] Patch to glib-2.22.3.ebuild incorporating interix6 fixes
Created attachment 216799 [details, diff] Avoid ld segfaults by not linking some stuff This excludes the gmodule utility library and some test directories, all of which crash ld for some reason.
Created attachment 216801 [details, diff] Some header fixes
Created attachment 216802 [details, diff] Updated so interix6 picks up AF_INET6 This is an updated version of the original patch fixing a compile failure on interix6
OK. Here is what I have. It compiles, that's about all I can say about it so far. There's got to be some way to fix gmodule... but that will take some investigating I suspect.
(In reply to comment #12) > could you also please sync? whoops... didn't sync sorry. Should be easy enough to "merge" however. Let me know if thats a hassle and I'll take care of it tomorrow. -gmt
(In reply to comment #18) > (In reply to comment #12) > > could you also please sync? > > whoops... didn't sync sorry. Should be easy enough to "merge" however. Let me > know if thats a hassle and I'll take care of it tomorrow. > > -gmt > don't bother - that should be easy enough to merge ... ;)
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #12) > > > could you also please sync? > > > > whoops... didn't sync sorry. Should be easy enough to "merge" however. Let me > > know if thats a hassle and I'll take care of it tomorrow. > > > > -gmt > > > > don't bother - that should be easy enough to merge ... ;) > I'm afraid I have determined inductively that the cause of the ld segfaults is itx-bind -- the interesting question becomes, then, what is it /about/ itx-bind that causes them? I'll have more time to mess around with this soon and post results (or lack of them) here. -gmt
(In reply to comment #20) > I'm afraid I have determined inductively that the cause of the ld segfaults is > itx-bind -- the interesting question becomes, then, what is it /about/ itx-bind > that causes them? I'll have more time to mess around with this soon and post > results (or lack of them) here. It seems I spoke too soon here. It seems that the real problem is somehow related to dependency resolution. GTG so can't go into details ATM but I'm still making slow progress here.
(In reply to comment #21) > (In reply to comment #20) > > I'm afraid I have determined inductively that the cause of the ld segfaults is > > itx-bind -- the interesting question becomes, then, what is it /about/ itx-bind > > that causes them? I'll have more time to mess around with this soon and post > > results (or lack of them) here. > > It seems I spoke too soon here. It seems that the real problem is somehow > related to dependency resolution. GTG so can't go into details ATM but I'm > still making slow progress here. > No, I am wrong again! But I have finally sussed it out. Somehow, _REENTRANT is the culprit! How wierd is that? I guess I will write some patches to cherry-pick the needed "_r" api's and leave _REENTRANT off for the rest, and see where that leaves i6. Well... first I want to look at some header files and gcc -E outputs, to convince myself that doing so is not completely broken. I guess the real solution to this is to create an itx-ld ebuild (or wedge it into binutils), that fixes whatever bug allows the MS-provided ld to segfault... I may take a shot at this sometime later, that is, if I am so lucky as to figure out the cause.
(In reply to comment #22) ug sorry, accidentally closed bug. prematurely.
Created attachment 217976 [details, diff] Updated ebuild patch (relative to rsync version) OK, I think I have this in a pseudo-acceptable state now. I've narrowed the ld segfault problem down to something to do with -D_REENTRANT being used against libgmodule-2.0. Obviously the root cause of the ld segfaults might still be worth investigating, but for now, I have incorporated a patch to the libgmodule Makefile.am to leave out _REENTRANT (and -lpthread, see below) during compilation of this library on Interix6. (that's coming in a separate ${FILESDIR} patch). Also, I have made some improvements to configure.in which afaics are going to be essential if glib is really going to use pthreads (how it was even linking before is a mystery to me -- maybe configure was just effectively disabling pthreads despite their being --enable'd). I think maybe configure needs similar modifications for a lot of gnome-ish stuff? maybe I'm making that up. Finally I have fixed some ${P} -> ${PN} snafus. And, pedantically, an ESL thinko :)
Created attachment 217977 [details, diff] Avoid ld segfault during compile Filter out -D_REENTRANT while building libgmodule, which keeps ld from segfaulting during the compile (no idea if this is really safe, however -- I don't see any pthread stuff in libgmodule fwiw).
Created attachment 217978 [details, diff] configure enhancements for pthreads on Interix In short, -D_REENTRANT -lpthread seems right. At the very least this gets rid of all those annoyting "-pthread" warnings :)
(In reply to comment #26) > In short, -D_REENTRANT -lpthread seems right. ugh. Unfortunately it seems that after glib is built this way, subsequent compiles of gconf cause the dreaded ld segfault. I'm going to spend some time trying to figure out how to compile the Interix ld from source, perhaps dancing around this problem with workarounds is just not a feasible option. What a PITA.
And we come full circle: http://sourceware.org/bugzilla/show_bug.cgi?id=2729 Apparently MS patched it but it was lost in the quagmire of copyright issues.
I did a little digging and the problem is definitely at linking gmodule. Here's the important bit of the truss output while linking: open("../gmodule/.libs/libgmodule-2.0.so", 0x1) open returned 6 fstat(6, 0x1940698) fstat ret: 0 dev: 0x40000000000043 ino: 0x001b6565 isatty(6) isatty returned 0 lseek(6, 0, 1) lseek returned 0 lseek(6, 0, 0) lseek returned 0 lseek(6, 0, 0) lseek returned 0 read(6, 0xb95a28, 4096) read returned 4096 0x1000 lseek(6, 12288, 0) lseek returned 0 read(6, 0xb95a28, 4096) read returned 4096 0x1000 read(6, 0xb95a28, 4096) read returned 4096 0x1000 lseek(6, 8192, 0) lseek returned 0 read(6, 0xb95a28, 4096) read returned 4096 0x1000 fstat(4, 0x1940698) fstat ret: 0 dev: 0x40000000000043 ino: 0x00007df7 isatty(4) isatty returned 0 lseek(4, 0, 1) lseek returned 0 lseek(4, 0, 0) lseek returned 0 lseek(4, 4607, 0) lseek returned 0 write(4, 0xba3b38, 1) write returned 1 lseek(4, 1024, 0) lseek returned 0 write(4, 0xba3b38, 112) write returned 112 0x70 lseek(4, 2560, 0) lseek returned 0 fault 8 sig=11 SIGSEGV reading 0x1C ntstatus=0xC0000005 pc=0x443914 (0x0, 0x1C) signal 11 SIGSEGV reading 0x1C ntstatus=0xC0000005 pc=0x443914 (0x0, 0x1C) null() null returned 0 signal 11 SIGSEGV reading 0x1C ntstatus=0xC0000005 pc=0x443914 (0x0, 0x1C) process killed by signal 11 For comparison, here's the output from successfully linking gthreads (1.so is my output file): open("../gthread/.libs/libgthread-2.0.so", 0x1) open returned 6 fstat(6, 0x1940698) fstat ret: 0 dev: 0x40000000000043 ino: 0x001b656f isatty(6) isatty returned 0 lseek(6, 0, 1) lseek returned 0 lseek(6, 0, 0) lseek returned 0 lseek(6, 0, 0) lseek returned 0 read(6, 0x195a28, 4096) read returned 4096 0x1000 lseek(6, 16384, 0) lseek returned 0 read(6, 0x195a28, 4096) read returned 4096 0x1000 read(6, 0x195a28, 4096) read returned 4096 0x1000 lseek(6, 8192, 0) lseek returned 0 read(6, 0x195a28, 4096) read returned 4096 0x1000 read(6, 0x195a28, 4096) read returned 4096 0x1000 lseek(6, 16384, 0) lseek returned 0 lseek(6, 11264, 0) lseek returned 0 read(6, 0x195a28, 4096) read returned 4096 0x1000 fstat(4, 0x1940698) fstat ret: 0 dev: 0x40000000000043 ino: 0x00007df7 isatty(4) isatty returned 0 lseek(4, 0, 1) lseek returned 0 lseek(4, 0, 0) lseek returned 0 lseek(4, 4607, 0) lseek returned 0 write(4, 0x1a6ab8, 1) write returned 1 lseek(4, 1024, 0) lseek returned 0 write(4, 0x1a6ab8, 112) write returned 112 0x70 lseek(4, 2560, 0) lseek returned 0 write(4, 0x1a6ab8, 20) write returned 20 0x14 lseek(4, 4608, 0) lseek returned 0 write(4, 0x1a6ab8, 576) write returned 576 0x240 lseek(4, 3584, 0) lseek returned 0 write(4, 0x1a6ab8, 54) write returned 54 0x36 lseek(4, 4096, 0) lseek returned 0 write(4, 0x1a6ab8, 189) write returned 189 0xbd lseek(4, 3072, 0) lseek returned 0 write(4, 0x1a6ab8, 64) write returned 64 0x40 lseek(4, 1536, 0) lseek returned 0 write(4, 0x1a6ab8, 32) write returned 32 0x20 lseek(4, 2048, 0) lseek returned 0 write(4, 0x1a6ab8, 12) write returned 12 0xc lseek(4, 5184, 0) lseek returned 0 write(4, 0x1a6ab8, 2193) write returned 2193 0x891 lseek(4, 376, 0) lseek returned 0 write(4, 0x1a6ab8, 280) write returned 280 0x118 lseek(4, 0, 0) lseek returned 0 write(4, 0x1a6ab8, 376) write returned 376 0x178 lseek(4, 60, 0) lseek returned 0 read(4, 0x1a6ab8, 4096) read returned 4096 0x1000 lseek(4, 62, 0) lseek returned 0 lseek(4, 216, 0) lseek returned 0 write(4, 0x1a6ab8, 4) write returned 4 lseek(4, 128, 0) lseek returned 0 lseek(4, 0, 0) lseek returned 0 read(4, 0x1a6ab8, 4096) read returned 4096 0x1000 read(4, 0x1a6ab8, 4096) read returned 3281 0xcd1 read(4, 0x1a6ab8, 4096) read returned 0 lseek(4, 7377, 0) lseek returned 0 lseek(4, 7378, 0) lseek returned 0 read(4, 0x1a6ab8, 4096) read returned 0 lseek(4, 7378, 0) lseek returned 0 lseek(4, 216, 0) lseek returned 0 write(4, 0x1a6ab8, 4) write returned 4 close(4) close returned 0 stat("1.so", 0x19406b0) stat ret: 0 dev: 0x40000000000043 ino: 0x00007df7 umask(0x0) umask returned 18 0x12 umask(0x12) umask returned 0 chmod("1.so", 0x1ED) chmod returned 0 lseek(0, 0, 1) lseek returned 0 lseek(0, 0, 0) lseek returned 0 lseek(3, 0, 1) lseek returned 0 lseek(3, 4300, 0) lseek returned 0 lseek(5, 316, 0) lseek returned 0 lseek(6, 11776, 0) lseek returned 0 exit(0) process exited with status 0 The read fault combined with NT error code 0xC0000005 definitely suggests it's some sort of memory access exception. I didn't get anything useful out of gdb, perhaps one of you guys could give it a go?
Not sure if prefix team could help now that Markus is not able to help a lot until 2013
(In reply to comment #28) > And we come full circle: http://sourceware.org/bugzilla/show_bug.cgi?id=2729 > Apparently MS patched it but it was lost in the quagmire of copyright issues. Everyone involved is well aware of this. I've all but given up hope. Indeed, I went back to the original patches and tried to see what was omitted and, well, a lot changed between 2001 (or whenever) and 2005. I doubt the etiology is anything so simple as a mere lack of interdependent merged patches. Meanwhile, 2005->2012 is a fairly punishing backport. My hunch is that anyone wanting to fix this is going to end up having to reverse engineer some stuff in Interix to get to the bottom of it. I accidentally blew away my git repository where I was working on this... but I remember trying awfuly hard to do it without any reverse-engineering and being extremely discouraged. Meanwhile, the writing is on the wall for Interix. Been that way for a while, but now, it's official. So the value proposition of digging deeper looks questionable. It's hard to imagine who will spend the time to resolve the matter. Maybe if somebody gets paid, or if Microsoft decided to open-source Interix now that they have deep-six'ed it (fat chance imo). If Marcus or whoever were to WONTFIX the open Interix bugs, I certainly wouldn't object.
Will reassign as mduft is on a long devaway and won't be able to take care of this
interix has no future
