use !elibc_glibc && append-libs -lintl I think it should have also use nls check Reproducible: Always
Did you notice how many platforms are supported in that realpath-1.15-r2.ebuild? Some of those more obscure ones may need that -lintl, so it seems safer to make another exception for uclibc than just decide based on use nls. By the way, have you already verified that it works fine with uclibc when skipping -lintl?
there I patch I've posted some time ago, it disables nls at all use nls || epatch "${FILESDIR}"/${P}-nonls.patch so !nls does not need -lintl
Ok, assigning to realpath maintainers.
Mmmh interesting. Could I see a broken build log? On my system using as-needed there is never a link against libintl.
/usr/lib/gcc/i586-gentoo-linux-uclibc/4.4.4/../../../../i586-gentoo-linux-uclibc/bin/ld: cannot find -lintl collect2: ld returned 1 exit status no need for full build log: use !elibc_glibc && append-libs -lintl this in unconditional if not using glibc patch since without nls a patch that disables at all nls code directly in the source, -lintl shouldn't not be added
(In reply to comment #5) > /usr/lib/gcc/i586-gentoo-linux-uclibc/4.4.4/../../../../i586-gentoo-linux-uclibc/bin/ld: > cannot find -lintl > collect2: ld returned 1 exit status > > no need for full build log: > use !elibc_glibc && append-libs -lintl I don't care. If I request the full build.log, then you should provide it. > > this in unconditional if not using glibc > patch since without nls a patch that disables at all nls code directly in the > source, -lintl shouldn't not be added >
neither I, if you have in mind to not listen to me at all. I've unmerged realpath
Created attachment 238769 [details] Buildlog of a failed build Same problem here. Attached is the requested buildlog. Can we reopen this bug?
(In reply to comment #8) > Created an attachment (id=238769) [details] > Buildlog of a failed build > > Same problem here. Attached is the requested buildlog. Can we reopen this bug? > Sure we can. I will take a look into it later.
No complains, so it is fixed. Thanks for reporting.