Subject: Re: iconv problems after update?
To: Takehiko NOZAKI <>
From: Matt Thomas <>
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/ 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
> (#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