bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21285: configure: <uniconv.h> not found despite --with-libunistring-


From: Marcin Cieslak
Subject: bug#21285: configure: <uniconv.h> not found despite --with-libunistring-prefix
Date: Mon, 14 Sep 2015 09:34:18 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]