samba-3.0.0beta1 codeset issue on non-Linux

Richard Sharpe rsharpe at
Mon Jun 16 16:58:16 GMT 2003

On Mon, 16 Jun 2003, David Lee wrote:

> On Sat, 14 Jun 2003, Andrew Bartlett wrote:
> > On Sat, 2003-06-14 at 13:13, TAKAHASHI Motonobu wrote:
> > > [David Lee had earlier written:]
> > >
> > > >>    b)  Bundle iconv (or part) with samba?
> > > >I'm not sure this would be a good solution.
> > >
> > > is the only reasonable solutions, I think.
> >
> > No, I don't think that including iconv() in samba in reasonable.  Why is
> > it better to have iconv inside samba than outside?
> Samba has always prided itself on its portablity to a wide range both of
> systems and of managerial environments.  It has been careful to mimimise
> the chain-of-prerequisite syndrome that has afflicted some other software.
> Accordingly it seems we ought to try, so far as is reasonably practicable,
> to work with the OS-provided "iconv()".  But _if_ we decide that Samba
> really has to use GNU-iconv, in whole or part, then that decision by the
> Samba Team (guided the participants in this thread) needs to be very well
> defended.  And we then need to know how to handle the many sites which,
> though having OS-iconv don't have GNU-iconv.
> Technically, would "configure" screech to a halt, saying "You must first
> install GNU-iconv"?
> And what about those sites with a strict and cautious managerial/political
> policy, where the sysadmin has already had to fight hard locally to get
> Samba approved, only then to discover that s/he is back at square one and
> now has to re-fight the same battle w.r.t. GNU-iconv.
> Making GNU-iconv a pre-requisite might run the risk of losing many
> potential users.

I think it would be bad to require GNU libiconv. :-)

Other reasons include those NAS vendors that are using Samba and would 
like to avoid dragging in yet another GPL'd package :-)
> But now let's step back from that brink.
> Is there not some way that we could let Samba choose and use a wide
> variety of "iconv"?  And that we provide some "fall back" options (and a
> structure?) to handle as many of the common cases as often as possible.
> Such as a code page to handle CP850<->UTF8 and/or CP850<->UCS-2LE, and
> others that folk might contribute?  (Would this be re-inventing a simpler,
> restricted GNU-iconv?)
> See also Richard Sharpe's parallel thread about BSD.

In fact, I believe that the native iconv on both Solaris and FreeBSD allow 
for CP850<->UTF8 and CP850<->UCS-2LE, but neither seem to handle US-ASCII 
(ASCII) to UCS-2LE, which is the test in Configire.

Richard Sharpe, rsharpe[at], rsharpe[at], 

More information about the samba-technical mailing list