Bug 1261 - Broken detection of iconv libs.
Summary: Broken detection of iconv libs.
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Build environment (show other bugs)
Version: 3.0.20
Hardware: Other FreeBSD
: P1 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-04-12 20:10 UTC by Timur Bakeyev
Modified: 2006-04-08 07:43 UTC (History)
0 users

See Also:

Patch tha reorder iconv tests (4.22 KB, patch)
2005-06-04 19:10 UTC, Timur Bakeyev
no flags Details
patch to remove detection of libbiconv altogether (693 bytes, patch)
2005-06-07 11:40 UTC, Gerald (Jerry) Carter (dead mail address)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur Bakeyev 2004-04-12 20:10:31 UTC
The way, how iconv libraries are detected is not completelly reliable and trustful.

For example, I do have on a FreeBSD system both libbiconv(iconv 2) and
libiconv(libiconv). Both packages are installed into /usr/local/{include,lib}
and feel themselves ok - no clashing, etc.

Unfortunatelly, for whatever reason libbiconv dosen't suit soamba needs(it
unable to convert whatever to UCS2-LE(although, it knows about UCS2)). So, tests
are fail and configuration script goes to the next directory, effectively
skipping perfectly wirking libiconv! Oops...

So, here is the problem - the way, how tests are done(the sequence) isn't
flexible enouth to catch such case. I guess, some reodering is necessary, so
uability tests were performed on a found library immediatelly and on failure the
flow would go farther, to the next library.

Of course, putting libiconv test above libbiconv test would solve(mask) the
problem too :)
Comment 1 Gerald (Jerry) Carter (dead mail address) 2005-02-01 11:43:21 UTC
Is this still an issue?  I know there has been work on the iconv 
detection since 3.0.3
Comment 2 Gerald (Jerry) Carter (dead mail address) 2005-02-07 07:43:36 UTC
marking as fixed in 3.0.11.  origiball reported 
against 3.0.3pre1.  Please reopen if not fixed
Comment 3 Timur Bakeyev 2005-06-04 19:10:14 UTC
This problem still exists in 3.0.15. It's seems, that proper fix with test of
all possible libraries in every passed subdirectory require sto much code
rewriting, so here I propose simple work around - test for libbiconv is moved to
the bottom of the list of possible libraries, so libiconv test comes first.
Still, if libiconv missing, libiconv detected properly.

Again, I'm wondering what libbiconv is useful for - even when it found, it's
usability test fails - library doesn't know anything about UCS2-LE.

Hope to see fix to this problem in .15, so we can abandon extra autoconf run
from FreeBSD port ;)

With regards,

Comment 4 Timur Bakeyev 2005-06-04 19:10:55 UTC
Created attachment 1260 [details]
Patch tha reorder iconv tests
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-06-07 11:40:29 UTC
Created attachment 1265 [details]
patch to remove detection of libbiconv altogether
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-06-07 12:00:40 UTC
patch tested and applied
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:27:40 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 8 Gerald (Jerry) Carter (dead mail address) 2006-04-08 07:43:39 UTC
Cleaning up versions.  There was no 3.0.15 so leaving it in bugzilla 
is causing some confusion.  Moving these nuder 3.0.20.
Originally files against 3.0.15preX.