> On Fri, Sep 22, 2000 at 03:31:59PM +0900, Tatsuo Ishii wrote:
> > pgc.o(.text+0x582): undefined reference to `pg_mbcliplen'
> > pgc.o(.text+0x953): undefined reference to `pg_mbcliplen'
> > ...
> > pg_mbcliplen cannot be used in the frontend. Remove them, please.
> 
> Is there any way to use a similar functionality in ecpg? I don't like to run
> truncate the text too early.

To truncate a mulbyte characters properly, you need to know what
encoding is used for a .pgc file that ecpg about to process. Currently
there is no mechanism in ecpg (and all other frontend) to know what
encoding is used for the .pgc files. This is a tough problem...
--
Tatsuo Ishii

Wed, 27 Sep 2000 10:44:01 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: ecpg is broken in current
Tatsuo Ishii wrote:

> > On Fri, Sep 22, 2000 at 03:31:59PM +0900, Tatsuo Ishii wrote:
> > > pgc.o(.text+0x582): undefined reference to `pg_mbcliplen'
> > > pgc.o(.text+0x953): undefined reference to `pg_mbcliplen'
> > > ...
> > > pg_mbcliplen cannot be used in the frontend. Remove them, please.
> >
> > Is there any way to use a similar functionality in ecpg? I don't like to run
> > truncate the text too early.
>
> To truncate a mulbyte characters properly, you need to know what
> encoding is used for a .pgc file that ecpg about to process. Currently
> there is no mechanism in ecpg (and all other frontend) to know what
> encoding is used for the .pgc files. This is a tough problem...
> --
> Tatsuo Ishii

I would recommend a command line option overriding an environment variable
(fallback). Isn't there some LC_* indicating the default encoding.
But on the other hand, compiling would most likely take place in 'C'.

Christof




Fri, 29 Sep 2000 19:04:06 +0200
Christof Petig <christof.petig@wtal.de>
Re: ecpg is broken in current