Subject: Re: iconv problems after update?
To: Takehiko NOZAKI <th-nozaki@netwrk.co.jp>
From: Matt Thomas <matt@3am-software.com>
List: current-users
Date: 03/18/2007 10:01:59
On Mar 17, 2007, at 2:12 AM, Takehiko NOZAKI wrote:

> hi, all
>
>>
>> CPPPICFLAGS seems used only to compile .so from *.s files.
>> I guess we should use CPICFLAGS instead even for cpp(1) flags
>> on compiling .so files. (it already contains -DPIC)
>
> thanks a lot. i had committed it now.
>
> please everyone use src/lib/libc/Makefile#rev1.129
> (don't forget cvs update -A option to remove sticky).
>
> $ cd ${BSDSRCDIR}/lib/libc
> $ cvs update -A Makefile
> $ make clean depend all install
>
>> The CSHLIBFLAGS was added by yamt@ in 2002, but matt@ recently  
>> changed
>> to PICFLAGS to avoid some other lossage, so reverting the change
>> doesn't seem wonderful.
>
> i think this is only cosmetic change, reverting to rev1.127 may no  
> harm.
>
>> Are you saying that the patch you posted
>> results in a working libc with iconv?  I don't understand the maze of
>> twisty preprocessor flags, all alike.
>
> yes, it works.
>
> some *.c sources(src/lib/libc/citrus/citrus_module.c etc.) call
> dlopen(3) to load the encoding module(/usr/lib/i18n/libUTF8.so and  
> so on).
>
> but there is the restriction that, dlopen(3) doesn't work for
> static linked binaries(because they are non-PIC objects).
> we don't want call it(it's useless), and we done it
> by #ifdef _I18N_DYNAMIC and CSHLIBFLAGS+=-D_I18N_DYNAMIC.
> (#ifdef __PIC__ is also usable, but the pre-defined macro is  
> peculiar to gcc).
>
> but cosmetic change CSHLIBFLAGS -> CPPPICFLAGS done in rev1.127 is  
> not corrent,
> CPPPICFLAGS affect *.s(asembler) sources only. we want it for *.c  
> sources.
> so tsutsui-san suggest to use CPICFLAGS.

You still need a better method.  MIPS and VAX don't compile objects  
just for shared libraries since there code is always pic.  so a  
static link will include a call to
dlopen.