samba - Jul 2004 - [BUG] iconv detection in 3.0.5rc1

I've found that the inner loop for iconv detection in a lib32 
subdirectory of the LOOK_DIR path doesn't work right.  Here are the 
problems I've noticed,

1) configure only tested lib32 on the first directory, /usr, this is 
because ICONV_FOUND was set to "yes" on the try of /usr/local/lib and 
never reset (if it should be) to "no" because all the conversion tests
were failures.  I've found that by moving,
	ICONV_FOUND="no"
inside the for loop,
	for i in $LOOK_DIRS ; do

permits configure to actually find the good installation of libiconv on 
my system under /opt/lib32.

2) I've also noticed that on the second iteration of that loop to try 
the lib32 directory that LDFLAGS is set to "-L/usr/lib -L/usr/lib32" 
when it should probably only be "-L/usr/lib32".  This is probably a 
sign that other variables are not being restored to their saved values.

---Jason Mader, FHWA/NHTSA National Crash Analysis Center,
The George Washington University, VA Campus

On Sun, Jul 11, 2004 at 01:33:39PM -0400, Jason Mader
wrote:
> I've found that the inner loop for iconv detection in a lib32 
> subdirectory of the LOOK_DIR path doesn't work right.  Here are the 
> problems I've noticed,
> 
> 1) configure only tested lib32 on the first directory, /usr, this is 
> because ICONV_FOUND was set to "yes" on the try of /usr/local/lib
and
> never reset (if it should be) to "no" because all the conversion
tests
> were failures.  I've found that by moving,
> 	ICONV_FOUND="no"
> inside the for loop,
> 	for i in $LOOK_DIRS ; do
> 
> permits configure to actually find the good installation of libiconv on 
> my system under /opt/lib32.
> 
> 2) I've also noticed that on the second iteration of that loop to try 
> the lib32 directory that LDFLAGS is set to "-L/usr/lib
-L/usr/lib32"
> when it should probably only be "-L/usr/lib32".  This is probably
a
> sign that other variables are not being restored to their saved values.
Hi Jason,

The patch at
       
http://marc.theaimsgroup.com/?l=samba-technical&m=108293814431661&w=2
still applies to the 3.0.5 configure.in. IIRC this was ok for your
environment when you tested it previously.

-- 
James Peach | jpeach@sgi.com | SGI Australian Software Group
I don't speak for SGI.