Marius Bakke <mba...@fastmail.com> writes: > ng0 <n...@we.make.ritual.n0.is> writes: > >> Marius Bakke <mba...@fastmail.com> writes: >> >>> ng0 <n...@we.make.ritual.n0.is> writes: >>> >>> >>>> I have my uclibc-ng system not booted: When I specify libiconv in the >>>> inputs, shouldn't it get reported by ldd? >>>> >>>> ng0@shadowwalker >>>> /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls >>>> mkpasswd whois >>>> ng0@shadowwalker >>>> /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd whois >>>> linux-vdso.so.1 (0x00007ffcd84fe000) >>>> libidn.so.11 => >>>> /gnu/store/sbj1kgn8bs91bn7ba9qk4n3l2rr7dxbr-libidn-1.32/lib/libidn.so.11 >>>> (0x00007f311084e000) >>>> libgcc_s.so.1 => >>>> /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 >>>> (0x00007f3110638000) >>>> libc.so.6 => >>>> /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 >>>> (0x00007f3110296000) >>>> >>>> /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 >>>> (0x00007f3110a81000) >>>> ng0@shadowwalker >>>> /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd mkpasswd >>>> linux-vdso.so.1 (0x00007ffed81c7000) >>>> libcrypt.so.1 => >>>> /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libcrypt.so.1 >>>> (0x00007fc0328e5000) >>>> libgcc_s.so.1 => >>>> /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 >>>> (0x00007fc0326cf000) >>>> libc.so.6 => >>>> /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 >>>> (0x00007fc03232d000) >>>> >>>> /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 >>>> (0x00007fc032b1c000) >>> >>> I'm guessing it silently picks the glibc one. FWIW the Gentoo ebuild >>> does the same thing. >> >> That is if your toolchain is glibc based. I have no uclibc-ng or musl >> gentoo system at the moment to check this. >> >>> Does uclibc-ng provide an iconv interface at all? >> >> Yes, but so far I wasn't able to get a response by the hardened project >> to get a comment on their "the iconv of uclibc and uclibc-ng is horrible >> at the moment" comment.. so I'll ask on gentoo-dev list about this, irc >> didn't work. >> >>> Maybe it can be circumvented by having [libc implementation] propagate >>> libiconv, instead of adding it as a direct input to packages. >> >> Possibly. I'm not yet at the point where I can build a system I like >> with this. > > I'm happy to commit this package now with the changes mentioned earlier, > if that's okay with you. Making it use an external iconv library feels > like "premature optimization", since it works fine with what we have.
Yes, okay for me.
