On Dec 24,  5:34pm, "Mehul N. Sanghvi" wrote:
} Tobias Nygren said the following on 8/3/2007 9:11 PM:
} > On Fri, 03 Aug 2007 19:29:26 -0400
} > "Mehul N. Sanghvi" <mehul.sanghvi@gmail.com> wrote:
} > 
} >> 'allo,
} >>
} >>       Every time I build something in pkgsrc, I get a linking error for 
} >> libiconv.  I usually end up doing an explicit export of LD_LIBRARY_PATH and 
} >> including /usr/pkg/lib in it.  Is there some variable I can set in my mk.conf 
} >> file that will ensure that I don't have to remember to do this each time ?
} > 
} > pkgsrc is supposed to encode the runpath into the binaries and if that
} > doesn't happen it is a bug. What version of Solaris are you on, what
} > architecture, what compiler and which ld(1) is the compiler using?
} > If you changed any of those you probably need to rebuild the
} > libtool-base package.
} 
} I am using Solaris 9/SPARC platform.  The compiler is gcc from 
} /usr/pkg/gcc3/bin and ld(1) is the standard Solaris ld(1) from /usr/ccs/bin. 
} Doing a simple thing like '/usr/pkg/gcc3/bin/gcc -v' will give me the following:
} 
} % type gcc
} gcc is hashed (/usr/pkg/gcc3/bin/gcc)
} 
} % gcc -v
} ld.so.1: gcc: fatal: libiconv.so.2: open failed: No such file or directory
} Killed
} 
} % ldd /usr/pkg/gcc3/bin/gcc
}        libiconv.so.2 =>         (file not found)
}        libc.so.1 =>     /usr/lib/libc.so.1
}        libdl.so.1 =>    /usr/lib/libdl.so.1
}        /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1
} 
} 
} I have a gcc compiler in /usr/local/bin which seems to work fine though:
} 
} % /usr/local/bin/gcc -v
} Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.1/specs
} Configured with: ../configure --with-as=/usr/ccs/bin/as 
} --with-ld=/usr/ccs/bin/ld --disable-nls --disable-libgcj --enable-languages=c,c++
} Thread model: posix
} gcc version 3.4.1
} 
} % ldd /usr/local/bin/gcc
}          libiconv.so.2 =>         /usr/local/lib/libiconv.so.2
}          libc.so.1 =>     /usr/lib/libc.so.1
}          libdl.so.1 =>    /usr/lib/libdl.so.1
}          /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1

     I'm guessing that this compiler came from sunfreeware and it is
what was used to compile the one in /usr/pkg/gcc3/bin/gcc.  I have seen
this problem in the past.  Basically, the version of GCC from
sunfreeware generates code that requires libiconv for some reason.  My
solution was to use the sunfreeware GCC to build my own GCC.  This GCC
required libiconv, but generated code that didn't.  So, I then used
this GCC to rebuild itself thus creating a version of GCC that didn't
require libiconv.  A royal pain in the neck to have to build GCC twice,
but it works.  Try setting LD_LIBRARY_PATH then doing 'make && make
upgrade' in lang/gcc3 to rebuild GCC.  Hopefully, the new version won't
require libiconv.  The reason for doing the plain 'make' first is that
one of the first things 'make upgrade' does is to delete the existing
package which would be a bit of a problem.

}-- End of excerpt from "Mehul N. Sanghvi"