Created attachment 313025 [details] i686-mingw32-emerge --info sudo ACCEPT_KEYWORDS=** i686-mingw32-emerge -av dev-libs/libiconv failed on install phase last log before errors is /usr/bin/install -c -m 644 ./iconv_open.3.html /usr/i686-mingw32/tmp/portage/dev-libs/libiconv-1.14/image//usr/share/doc/libiconv-1.14/html/iconv_open.3.html /usr/bin/install -c -m 644 ./iconv_open_into.3.html /usr/i686-mingw32/tmp/portage/dev-libs/libiconv-1.14/image//usr/share/doc/libiconv-1.14/html/iconv_open_into.3.html make[1]: Leaving directory `/usr/i686-mingw32/tmp/portage/dev-libs/libiconv-1.14/work/libiconv-1.14/man' * ERROR: dev-libs/libiconv-1.14 failed (install phase): * unable to read SONAME from libiconv.dll * * Call stack: * ebuild.sh, line 85: Called src_install * environment, line 1036: Called gen_usr_ldscript '-a' 'iconv' 'charset' * environment, line 692: Called die * The specific snippet of code: * [[ -z ${tlib} ]] && die "unable to read SONAME from ${lib}"; * * If you need support, post the output of 'emerge --info =dev-libs/libiconv-1.14', * the complete build log and the output of 'emerge -pqv =dev-libs/libiconv-1.14'. * The complete build log is located at '/usr/i686-mingw32/tmp/portage/dev-libs/libiconv-1.14/temp/build.log'. * The ebuild environment file is located at '/usr/i686-mingw32/tmp/portage/dev-libs/libiconv-1.14/temp/environment'. * S: '/usr/i686-mingw32/tmp/portage/dev-libs/libiconv-1.14/work/libiconv-1.14' >>> Failed to emerge dev-libs/libiconv-1.14 for /usr/i686-mingw32/, Log file: >>> '/usr/i686-mingw32/tmp/portage/dev-libs/libiconv-1.14/temp/build.log'
Please attach the entire build log to this bug report.
Created attachment 313057 [details] Full build log
Could you post the following command result? scanelf -qF'%S#F' /usr/i686-pc-mingw32/tmp/portage/dev-libs/libiconv-1.14/images/usr/lib/libiconv.dll (libiconv.dll path may be different)
scanelf -qF'%S#F' /usr/i686-pc-mingw32/tmp/portage/dev-libs/libiconv-1.14/image/usr/lib/libiconv.dll.a gives nothing. rusinov@localhost ~ $ scanelf -qF'%S#F' /usr/i686-pc-mingw32/tmp/portage/dev-libs/libiconv-1.14/image/usr/lib/libiconv.dll.a rusinov@localhost ~ $
(In reply to comment #4) > scanelf -qF'%S#F' > /usr/i686-pc-mingw32/tmp/portage/dev-libs/libiconv-1.14/image/usr/lib/ > libiconv.dll.a > > gives nothing. > > rusinov@localhost ~ $ scanelf -qF'%S#F' > /usr/i686-pc-mingw32/tmp/portage/dev-libs/libiconv-1.14/image/usr/lib/ > libiconv.dll.a > rusinov@localhost ~ $ ah "-q" may suppressed error. how about scanelf -vvF'%S#F' ?
Nothing too.
@toolchain This is CHOST="i686-mingw32" issue. Dose this has a way to retrieve SONAME? If not, this platform also listed to gen_usr_ldscript's case matching?
I'm afraid no, which way I have to verify it ?
i'm thinking we should just disable this code for all targets where Gentoo isn't the native booting OS i.e. for non-linux and non-bsd systems, have the function do nothing at all this will allow us to gut quite a bit of code (mach-o and such), but it might mean we have to fix an assumption or two in the ebuilds that use this function. i think that's a small price to pay though to tweak the API of the func.
(In reply to comment #9) > i'm thinking we should just disable this code for all targets where Gentoo > isn't the native booting OS > > i.e. for non-linux and non-bsd systems, have the function do nothing at all > > this will allow us to gut quite a bit of code (mach-o and such), but it > might mean we have to fix an assumption or two in the ebuilds that use this > function. i think that's a small price to pay though to tweak the API of > the func. Yes, but I'm not looking forward to it, since it will break each and every OSX system badly, and IIRC also on ELF systems this caused some problems. At least on OSX, a zlib upgrade will destroy the entire Prefix offset, unless Portage's preserve-libs catches this problem these days. If so, there is hope, otherwise, I'd prefer not to bother.
Rendering the ebuild assumptions to be valid for one platform and invalid for another doesn't feel like an improvement at all, just more $CHOST cases...
(In reply to comment #10) i don't follow. why would this cause a problem ? the point of `gen_usr_ldscript -a` is to move the shared lib from /usr/lib to /lib and drop a linker script in /usr/lib. if, instead, that did nothing at all, you'd have the shared library in /usr/lib and no linker script. the shared library isn't being deleted anywhere. (In reply to comment #11) the point is to adjust the API so you can't assume anything at all. you run `gen_usr_ldscript -a` at the end of the install steps and do not attempt to touch the shared library in /lib or /usr/lib. this is how i've always used it.
Mach-O uses absolute references to the shared libs (libxxx.dylib). I broke all systems when I introduced gen_usr_ldscript for OSX. On the first zlib upgrade the breakage became visible, because everything, including gcc was referring to usr/lib/libz.dylib -- which after the update resided in lib/libz.dylib. A kernel trap was all that one could get. Making gen_usr_ldscript a noop, effectively introduces the same problem once again.
(In reply to comment #13) man, that's fsckin brain dead why was gen_usr_ldscript support added to OS X at all ? we know why it gets used on Linux systems where Gentoo is booting from, but seeing as we don't boot OS X at all ... depending on where the /usr merge takes us, this might even become a nop for all targets ...
basically because some components at that time (and might still do) relied on libs being in /lib, like existence checks and stuff like that Indeed, /usr merge. Hence, I hope preserve-libs just preserves lib/libz.dylib when usr/lib/libz.dylib is installed, and all is fine (with a rebuild of almost everything). If you have an ETA here, I'd like to know. Since I recall Prefix tree having modications to ebuilds that rely on gen_usr_ldscript (ncurses, I think), this means more migration has to be performed than just changing the behaviour of the function. It is not always as simple as just moving a shared object to another location, in particular on Mach-O systems. Getting rid of all this stuff would be a plus, though.
(In reply to comment #15) for packages that make assumptions about a lib being in /usr/lib vs /lib, let's file bugs and get those fixed today. that's not something packages should need to know at all, and can be done independently of changing gen_usr_ldscript. as for ETA, this isn't a pressing issue as prefix currently has higher priority over mingw. so if you need time to sort/test first, that's fine.
I'll try out what happens if I change it in an existing Prefix, as well as if I bootstrap one from scratch with the change.
*** Bug 420087 has been marked as a duplicate of this bug. ***
Ok, I disabled gen_usr_ldscript and performed a fresh bootstrap. The contents of /lib after `emerge -e system` is as follows: bash-3.2$ ls lib/ bundle1.o dylib1.10.5.o libgcc_s.1.dylib libncurses.5.dylib cpp dylib1.o libgcc_s.10.4.dylib libncurses.dylib crt1.10.5.o gcrt1.o libgcc_s.10.5.dylib libncursesw.5.dylib crt1.10.6.o lazydylib1.o libgcc_s_ppc64.1.dylib libncursesw.dylib crt1.o libcurses.dylib libgcc_s_x86_64.1.dylib rcscripts bash-3.2$ That is basically everything gcc-config copies/creates + ncurses + baselayout-prefix. The ncurses stuff is because that ebuild had to be changed to manually install libs in /lib, otherwise incorrect libs would result. That needs to be undone, risking major breakage. I'm going to experiment with undoing this next thing.
changing gen_usr_ldscript to be a noop on existing Darwin prefix systems badly breaks when gettext is updated Portage can't preserve-libs seems to fail here, even though it preserves lib/libiconv.2.5.1.dylib. Since lib/libiconv.2.dylib (the "soname") isn't preserved, all breaks. Unclear to me why still. Note that nearly everything is linked against gettext (intl/iconv) in non-glibc system.
*** Bug 426416 has been marked as a duplicate of this bug. ***
(In reply to comment #20) well, we can leave the darwin logic alone (for now). any reason to keep it for any other system ? i'd just change the logic to: case ${CTARGET:-${CHOST}} in *-darwin*) <existing logic>;; *linux*) use prefix && return 0 <existing logic>;; *) return 0;; esac
That's fine in principle. If you allow me some time, I'd like to test this on Solaris and Linux first. Since we have a copy of the eclass for Prefix, you could also just make the change in gx86. We'd have to take care not to take over that change. If you know a way in which we can disable this function for "new" installs, but leave it functioning as is for old/existing installs, that would move things forwards too.
(In reply to comment #23) i'll make the change in gentoo-x86 (since this is affecting more than prefix systems), and then you can test & post your results here. http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.112&r2=1.113
Created attachment 319214 [details, diff] patch for toolchain-funcs.eclass (In reply to comment #24) > (In reply to comment #23) > > i'll make the change in gentoo-x86 (since this is affecting more than prefix > systems), and then you can test & post your results here. > > http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.112&r2=1.113 Please don't forget the Gentoo/FreeBSD. toolchain-funcs.eclass Revision 1.112 # ls -1 /var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/image/lib64/ libalias.so.7 libc.so.7 libcam.so.6 libgeom.so.5 libipsec.so.4 libjail.so.1 libkiconv.so.4 libkvm.so.5 libm.so.5 libmd.so.5 libprocstat.so.1 libsbuf.so.6 libthr.so.3 libufs.so.6 libutil.so.9 Revision 1.113 # ls -1 /var/tmp/portage/sys-freebsd/freebsd-lib-9.0-r3/image/lib64/ libc.so.7
(In reply to comment #25) > Created attachment 319214 [details, diff] [details, diff] > patch for toolchain-funcs.eclass > > (In reply to comment #24) > > (In reply to comment #23) > > > > i'll make the change in gentoo-x86 (since this is affecting more than prefix > > systems), and then you can test & post your results here. > > > > http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.112&r2=1.113 > > Please don't forget the Gentoo/FreeBSD. We should probably also include Gentoo/OpenBSD and Gentoo/NetBSD in this fix. blueness and maksbotan are looking into reviving Gentoo/OpenBSD and we have a really enthusiatic contributor working to revive Gentoo/NetBSD. It would be best to handle all of the BSDs in a single patch.
(In reply to comment #26) > (In reply to comment #25) > > Created attachment 319214 [details, diff] [details, diff] [details, diff] > > patch for toolchain-funcs.eclass > > > > (In reply to comment #24) > > > (In reply to comment #23) > > > > > > i'll make the change in gentoo-x86 (since this is affecting more than prefix > > > systems), and then you can test & post your results here. > > > > > > http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.112&r2=1.113 > > > > Please don't forget the Gentoo/FreeBSD. > > We should probably also include Gentoo/OpenBSD and Gentoo/NetBSD in this > fix. blueness and maksbotan are looking into reviving Gentoo/OpenBSD and we > have a really enthusiatic contributor working to revive Gentoo/NetBSD. It > would be best to handle all of the BSDs in a single patch. the *linux*) use prefix && return 0 ;; case should be *) use prefix && return 0 ;; imho; the *linux*) case to generate the ldscript should go back to its ancient *) case, as other targets are matched before.
Created attachment 319222 [details, diff] new patch for toolchain-funcs.eclass Native Gentoo system will run gen_usr_ldscript.
(In reply to comment #27) no. any systems that want this behavior will have to opt in. the default moving forward is for gen_usr_ldscript to be legacy. list the exact tuples you care about for bsd systems.
(In reply to comment #29) > (In reply to comment #27) > > no. any systems that want this behavior will have to opt in. the default > moving forward is for gen_usr_ldscript to be legacy. what is the rationale behind making this legacy ? > list the exact tuples you care about for bsd systems. any non prefix, elf + binutils based system ? opt-out seems saner...
(In reply to comment #30) as noted elsewhere, /usr merge is happening as for your proposed prefixes, those don't make sense. an elf+binutils system is bare metal which means it usually has no filesystem to boot let alone worry about "mounting". post the bsd tuples you care about and we can add them.
(In reply to comment #31) > (In reply to comment #30) > > as noted elsewhere, /usr merge is happening .... on linux packages moving to /usr will just stop calling gen_usr_ldscript rather than relying on a complex logic in the function anyway. > as for your proposed prefixes, those don't make sense. an elf+binutils > system is bare metal which means it usually has no filesystem to boot let > alone worry about "mounting". but the current code will handle it just fine, and anyway, this is under the assumption that if its not prefix then we'd like to reach that point some day... mingw is more the exception than the rule > post the bsd tuples you care about and we can > add them. _I_ care about *freebsd*, but then see comment #26 I dont see why we should make porting to new systems harder than what it already is.
(In reply to comment #32) as noted, it isn't just prefix and linux systems where a split /usr makes no sense ... there are less systems that want split /usr than non-split. mingw isn't the only one. so no, using a fallback glob makes no sense. i don't really buy that this makes porting "harder". the burden here is trivial, and for the systems where it matters (which is small), it's easy to locate. i've added *-freebsd* to the list of systems which do split /usr. http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.113&r2=1.114
(In reply to comment #29) > (In reply to comment #27) > > no. any systems that want this behavior will have to opt in. the default > moving forward is for gen_usr_ldscript to be legacy. > > list the exact tuples you care about for bsd systems. Who decided this? I use this in sys-fs/zfs and I intend to maintain the split for our users as long as possible. If we must break it, then that is fine, but for now, it appears that everyone is doing what they can to maintain it. Making this opt-in will give ports an unnecesary pain to debug and quite frankly, it is unnecessary. Why not restrict this to userland_GNU? That is the only place where this merge might happen. If you insist on making this opt-in, please add openbsd and netbsd to the list. As I noted above, there are efforts to revive the ports. There is no point in giving them yet another issue to debug.
Forgive me for possibly being dense, but is there an official Gentoo policy on using /lib versus /usr/lib, which libraries go into which directories, whether the system is supposed to be bootable without /usr/lib, and how *much* of the system is supposed to be bootable without /usr/lib? If there is no hard and fast rule for determining which libraries are supposed to be in /lib, then we basically have a clusterfsck of conflicting opinions.
(In reply to comment #34) userland_GNU has nothing to do with it. if you want to support split /usr in your packages, nothing is stopping you from doing that. when we get to the day of Linux /usr being merged, we probably will add an IUSE=split-usr flag for people to opt into it on their random systems. i need the exact tuples for openbsd/netbsd. i'm not going to try and guess. (In reply to comment #35) read the threads on gentoo-dev mailing list
I'd personally love a way to opt *out* of the split /usr right now. My /usr is in the same file system as my /, and the presence of the ldscripts in /usr/lib feels like a needless hack for me. Could there be a FEATURES flag added to Portage that would control whether gen_usr_ldscript does its thing or is a no-op? Then individual profiles could set it enabled or disabled by default.
(In reply to comment #36) > (In reply to comment #34) > > userland_GNU has nothing to do with it. if you want to support split /usr > in your packages, nothing is stopping you from doing that. when we get to > the day of Linux /usr being merged, we probably will add an IUSE=split-usr > flag for people to opt into it on their random systems. > > i need the exact tuples for openbsd/netbsd. i'm not going to try and guess. `sed 's/*linux*|*-freebsd*)/*linux*|*-freebsd*|*-openbsd*|*-netbsd*)/'` would work.
(In reply to comment #37) this isn't the place to debate /usr merge. take it to the gentoo-dev mailing list (where there have been plenty of threads already). (In reply to comment #38) that regex doesn't actually work, but it can deduce what you want from it ;) http://sources.gentoo.org/eclass/toolchain-funcs.eclass?r1=1.114&r2=1.115
I've tried emerging dev-libs/libiconv in mingw environment (which didn't work before due to this issue; see also bug 420087) and can confirm that it now installs fine.
@toolchain: I would like to ask your opinion on this bug wrt Linux. Once separate /usr support is implemented with either an initramfs or the busybox[sep-usr] option and we give users time to migrate to one or the other of these two options, which will hide the /usr split, do you feel that we still need this function on Linux, or should we make it optional or drop it??
(In reply to comment #41) see comment 29 and comment 31 (and probably others)
(In reply to comment #23) > That's fine in principle. If you allow me some time, I'd like to test this > on Solaris and Linux first. For the records (done within my rather old but stable prefix fork): AIX: No problem. HP-UX and Interix: Dynamic linkage stays intact across /lib->/usr/lib move, but removing a shared library in use (fex /lib/libncurses) triggers bug#199868.
When we get ready to do this, it looks like we may have to make it an opt-out setting, or set up a separate profile people can use if they don't want this to be disabled. It seems like we have some folks on Linux who are going to refuse to use initramfs or busybox[sep-usr] no matter what we do.
adding a magic env var for people to set should be easy. not sure a sep profile is necessary to set a single variable.
In Prefix we currently do such hack: http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/eclass/toolchain-funcs.eclass#L637 New bootstraps in Prefix get PREFIX_DISABLE_GEN_USR_LDSCRIPT set to yes in etc/portage/make.conf
(In reply to William Hubbs from comment #44) > When we get ready to do this, it looks like we may have to make it an > opt-out setting, or set up a separate profile people can use if they > don't want this to be disabled. > > It seems like we have some folks on Linux who are going to refuse to use > initramfs or busybox[sep-usr] no matter what we do. The council has now declared that running without an initramfs or busybox[sep-usr] (preferably an initramfs) is not supported as of 1-Nov-2013. Therefore, I propose just turning off gen_usr_ldscript on Linux after that date. Thoughts? William
The council has left the way this is handled to maintainer discression.
Created attachment 359640 [details, diff] disable-gen-ldscript.patch @toolchain: I am not a toolchain maintainer, but this seems to be the cleanest way forward. If you apply this patch, it makes gen_usr_ldscript noop on linux platforms, but leaves it alone for other platforms where it is still used. Thoughts about applying this on or after 1 nov would be appreciated. Thanks, William
(In reply to William Hubbs from comment #49) well, we're still going to have calls to gen_usr_ldscript sprinkled in ebuilds to support other systems (like bsd). so it's not like maintenance costs go down in terms of making sure this func still does what it's supposed to. i don't really have a problem with this change, but i also would be fine with (i'm assuming i got the logic right ... haven't tested): if [[ -z ${GENTOO_ENABLE_SPLIT_USR} ]] ; then case ${CTARGET:-${CHOST}} in *-darwin*) GENTOO_ENABLE_SPLIT_USR='yes' ;; *-freebsd*|*-openbsd*|*-netbsd*) use prefix || GENTOO_ENABLE_SPLIT_USR='yes' ;; esac fi if [[ ${GENTOO_ENABLE_SPLIT_USR} != "yes" ]] ; then return 0 fi
Because also on Darwin I want to move away from this, the Prefix overlay uses a version of gen_usr_ldscript that listens to a special var that disables gen_usr_ldscript. Perhaps something like this would work for everyone involved here if we'd set it through a (new) profile?
(In reply to Fabian Groffen from comment #51) that was the reason i wrote the code above. with that in place, your prefix overlays can explicitly set that var to "no" and it'll disable things.
(In reply to SpanKY from comment #52) > that was the reason i wrote the code above. with that in place, your prefix > overlays can explicitly set that var to "no" and it'll disable things. Ah, yes... needed more coffee this morning. Sorry
(In reply to SpanKY from comment #50) if there's no other feedback, i'll probably merge this in the next week
(In reply to Fabian Groffen from comment #53) > (In reply to SpanKY from comment #52) > > that was the reason i wrote the code above. with that in place, your prefix > > overlays can explicitly set that var to "no" and it'll disable things. > > Ah, yes... needed more coffee this morning. Sorry @grobian: I'm a little lost here. Why does it matter whether libraries go in /lib* or /usr/lib* on prefix? The only reason I know of for putting libraries in /lib* is so that systems can boot, but prefixes don't boot, so I'm a bit confused about why you would even need gen_usr_ldscript to do anything at all on prefix.
(In reply to William Hubbs from comment #55) Historical mistake, we decided to follow Gentoo Linux closely, including gen_usr_ldscript. FYI, new Prefix bootstraps already disable the use of it. Darwin/Mach-O stores absolute references to shared libraries, hence if you move them, you simply break all applications that rely on it. preserve-libs helps a lot in this case, but it isn't quite perfect, therefore I didn't just disable it globally through the profiles yet. All existing prefixes that I changed this setting for in the past have broken sofar (Darwin/Solaris), usually on zlib.
revised version: # Eventually we'd like to get rid of this func completely #417451 if [[ -z ${GENTOO_ENABLE_SPLIT_USR} ]] ; then case ${CTARGET:-${CHOST}} in *-darwin*) GENTOO_ENABLE_SPLIT_USR='yes' ;; *-freebsd*|*-openbsd*|*-netbsd*) use prefix || GENTOO_ENABLE_SPLIT_USR='yes' ;; *linux*) # Do a sanity check on users to see if they have a split-/usr. # If so, for now, we warn & still do this stuff. # The ROOT hack isn't entirely correct, but we don't really care. # If you're deploying binpkgs, you can sort it out yourself. if [[ ${ROOT} == "/" && $(stat -c %d /) != "$(stat -c %d /usr)" ]] ; then ewarn "You have a /usr mount point, but have not set GENTOO_ENABLE_SPLIT_USR=yes" ewarn "in your make.conf. Please do so now as future builds will stop setting" ewarn "this for you automatically and your system might stop booting." ewarn "See http://bugs.gentoo.org/417451 for more details." GENTOO_ENABLE_SPLIT_USR='yes' fi ;; esac fi if [[ ${GENTOO_ENABLE_SPLIT_USR} != "yes" ]] ; then return 0 fi
Ping, where are we on this bug?
Created attachment 394428 [details, diff] gen_usr_ldscript.patch @vapier: This is the patch that implements the last suggestion.
Comment on attachment 394428 [details, diff] gen_usr_ldscript.patch >+ *Linux*) you've added a minor but significant error ;). my version had "*linux*". at any rate, we need a news item put together before this is committed. feel like doing that and i'll take care of pushing the eclass update ?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cc8063d4318a6594ac8ae94e99c2a6fe484198bd commit cc8063d4318a6594ac8ae94e99c2a6fe484198bd Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2019-07-14 20:17:43 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2019-07-18 15:13:13 +0000 usr-ldscript.eclass: return early if USE=split-usr is disabled Bug: https://bugs.gentoo.org/417451 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/usr-ldscript.eclass | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Closing as IUSE=split-usr is an available knob to opt out of ldscript.
