GNU bug report logs -
#21285
configure: <uniconv.h> not found despite --with-libunistring-prefix
Previous Next
Reported by: Marcin Cieslak <saper <at> saper.info>
Date: Tue, 18 Aug 2015 07:06:02 UTC
Severity: minor
Done: Marcin Cieslak <saper <at> saper.info>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On Sat, 22 Aug 2015, Mark H Weaver wrote:
> could be eliminated by taking the following steps:
>
> * export CPATH=/home/admini/saper/sparcv9/include
> * export LIBRARY_PATH=/home/admini/saper/sparcv9/lib
> * export PKG_CONFIG_PATH=/home/admini/saper/sparcv9/lib/pkgconfig
> * install 'pkg-config' and make sure it's in PATH
pkg-config requires glib which does not currently compile here
due to iconv signature mismatch problem (the internal one).
Because I compile 32-bit code with the "sparcv7"
prefix and 64-bit code "sparcv9" prefix I'd need to maintain
two pkg-config instances. Doable, but not a priority.
Also I need to make sure that no global pkg-config is used,
since this box has tons of leftover, unmaintained packages
installed in /usr/local.
And this seems more useful (sometimes) to report bugs - all options
are explicitly listed on the command line, without any
need to rely on $PATH or pkg-config.
> There may be additional difficulties related to the fact that you appear
> to be cross-compiling. Did you read the section "Cross building Guile"
> in our README?
That's not a true cross-compile, it's a so-called "multilib" configuration.
Autoconf kind of knows sparc64-sun-solaris2.9 is the same platform
as sparc-sun-solaris2.9. Setting --host to
the sparc64-sun-solaris2.9 is actually only useful to identify the platform
for the tools that identify their target on startup.
(It does not seem to change much else, I have to supply "-m64" option
to get a SPARCv9 build anyway). Also I remember getting this problem
without setting --host or --build at all.
>
> > /* snip */
> >
> > configure:14672: checking for libunistring
>
> This doesn't appear to be the same 'configure' script that we distribute
> with guile-2.0.11. The line numbers are different. Did you regenerate
> it?
No, the line numbers are off, at least on the shells I have tried
(/bin/sh, /usr/xpg4/bin/sh POSIX shell). Recent bash works better.
> > configure:14694: /home/admini/saper/sparcv7/bin/gcc -m64 -mcpu=ultrasparc3 -o conftest -g -O2 conftest.c -lunistring >&5
> > conftest.c:123:21: fatal error: uniconv.h: No such file or directory
> > #include <uniconv.h>
> > ^
> > compilation terminated.
>
> I agree that this is likely a problem in the m4 code, which we import
> from gnulib, but for now, can you see if the above suggestions work for
> you and report back?
I have some other issues with libunistring at the moment - it made it
to compile and install but it does not seem to run properly.
Right now I can't reproduce the above problem, but the configure
complains about the lack of iconv support in libunistring, which
is not true. But this is related to the libunistring not
working correctly and is probably not related to guile.
Once I solve the underlying libunistring issues (http://savannah.gnu.org/bugs/?45783,
http://savannah.gnu.org/bugs/?45784 identified so far)
will try guile's configure again and report back.
~Marcin
This bug report was last modified 9 years and 252 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.