Re: [PATCH] gnu: Add whois.

[ng0 <ng0@we.make.ritual.n0.is>]

Marius Bakke <mbakke@fastmail.com> writes:

> ng0 <ng0@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.