Re: [PATCH] gnu: Add whois.

[Marius Bakke]

ng0 <address@hidden> writes:

> Marius Bakke <address@hidden> writes:
>
>> ng0 <address@hidden> writes:
>>
>>
>>> I have my uclibc-ng system not booted: When I specify libiconv in the
>>> inputs, shouldn't it get reported by ldd?
>>>
>>> address@hidden 
>>> /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls
>>> mkpasswd  whois
>>> address@hidden 
>>> /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)
>>> address@hidden 
>>> /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.