On Solaris 2.9 (probably earlier) if the GNU iconv package is installed, the apr-util configuration properly detects whether or not libiconv is installed, but fails to test to see whether or not the -liconv option needs to be added to the LIBS or EXTRA_LIBS variables (it does - since the functions are NOT present in the system libraries. I think that the best way to solve this would be to include a test in the apr-util/configure script that, if iconv.h is detected, then tests to see if -liconv is necessary to use its functions.
version 2.0.52, on solaris 9, with SMCiconv installed from sunfreeware, final link is missing -liconv; missing from build/config_vars.mk (probably AP_LIBS)
Can you add two attachments to this bug report: 1) the complete output of the configure script 2) the srclib/apr-util/config.log file
Looking for info from the reporter.
Hi there, I might have an update on this, though my problem was on *install* phase. I.e., httpd compiled fine with included apr; then "make install" failed to relink libaprutil saying it couldn't find libiconv. The following solved the issue: CFLAGS='-I/usr/include' CPPFLAGS='-I/usr/local/lib' \ LDFLAGS='-L/usr/local/lib' \ ./configure ... --with-included-apr Indeed, "iconv.h" is in /usr/include, whereas the library is in /usr/local/lib. Further details: $ uname -a SunOS zaqar8 5.10 Generic_138888-05 sun4u sparc SUNW,Sun-Fire-V490 $ isainfo -v 64-bit sparcv9 applications vis2 vis 32-bit sparc applications vis2 vis v8plus div32 mul32 $ pkginfo -l SMCliconv PKGINST: SMCliconv NAME: libiconv CATEGORY: application ARCH: sparc VERSION: 1.11 BASEDIR: /usr/local VENDOR: Bruno Haible PSTAMP: Steve Christensen INSTDATE: Jan 17 2011 17:10 EMAIL: steve@smc.vnet.net STATUS: completely installed FILES: 48 installed pathnames 8 shared pathnames 10 directories 3 executables 4991 blocks used (approx) HTH! ^m'e
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.