[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [platform-testers] texinfo-6.5.90 pretest on Solaris 10
From: |
Bruno Haible |
Subject: |
Re: [platform-testers] texinfo-6.5.90 pretest on Solaris 10 |
Date: |
Sat, 05 Jan 2019 16:30:02 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; ) |
> In spite of the comment in the code, the 'iconv'
> gnulib is already supposed to be in use.
Indeed, both the files
gnulib/m4/gnulib-cache.m4
tp/Texinfo/XS/gnulib/m4/gnulib-cache.m4
show that the gnulib module 'iconv' is already in use.
> I am not sure that gnulib actually does take care of missing iconv_t -
> it's not mentioned in the gnulib manual. I don't think gnulib is
> providing an iconv implementation.
Correct; the 'iconv' module only connects to an iconv() implementation
that is already installed.
> I discovered there is an "iconv-h" module, which is
> not mentioned anywhere in the gnulib manual. Do you know if that is
> the module we need?
This is not the one you need; it provides only the <iconv.h> file,
but no actual iconv() implementation.
> I am not sure why iconv is not being found when configuring the XS
> subdirectory. In the configure log "log1" that you sent, at the top
> level there is:
>
> checking for iconv... yes
> checking for working iconv... yes
> checking how to link with libiconv...
> /home/haible/prefix-x86_64/lib/libiconv.so
> -R/home/haible/prefix-x86_64/lib
>
> but under the XS subdirectory, it is:
>
> checking for iconv... no, consider installing GNU libiconv
Indeed. There are two config.status files, in the top-level
directory and in tp/Texinfo/XS. Both have been created with the
same --prefix, CC, LDFLAGS, CPPFLAGS settings:
$ ./config.status --version
GNU Texinfo config.status 6.5.90
configured by ../configure, generated by GNU Autoconf 2.69,
with options "'--prefix=/home/haible/prefix-x86_64' 'CC=cc -xarch=generic64
-O' 'LDFLAGS=-L/home/haible/prefix-x86_64/lib'
'CPPFLAGS=-I/home/haible/prefix-x86_64/include'"
...
$ cd tp/Texinfo/XS/
$ ./config.status --version
texinfo config.status 0
configured by ../../../../tp/Texinfo/XS/configure, generated by GNU Autoconf
2.69,
with options "'--disable-option-checking'
'--prefix=/home/haible/prefix-x86_64' 'CC=cc -xarch=generic64 -O'
'LDFLAGS=-L/home/haible/prefix-x86_64/lib'
'CPPFLAGS=-I/home/haible/prefix-x86_64/include' '--cache-file=/dev/null'
'--srcdir=../../../../tp/Texinfo/XS'"
...
But the config.log files show different results:
In the config.log of the top-level directory:
configure:9340: cc -xarch=generic64 -O -D_STDC_C99= -o conftest -g
-I/home/haible/prefix-x86_64/include -D_REENTRANT
-L/home/haible/prefix-x86_64/lib conftest.c
/home/haible/prefix-x86_64/lib/libiconv.so -R/home/haible/prefix-x86_64/lib >&5
configure:9340: $? = 0
configure:9350: result: yes
In the config.log of the tp/Texinfo/XS directory:
configure:7518: cc -o conftest -g -I/home/haible/prefix-x86_64/include
-L/home/haible/prefix-x86_64/lib conftest.c
/home/haible/prefix-x86_64/lib/libiconv.so -R/home/haible/prefix-x86_64/lib >&5
ld: fatal: file /home/haible/prefix-x86_64/lib/libiconv.so: wrong ELF class:
ELFCLASS64
ld: fatal: file processing errors. No output written to conftest
configure:7518: $? = 1
As you can see, it does not use $CC (which I set to a 64-bit compiler)
but 'cc' (which happens to be a 32-bit compiler - thus causing a mismatch
with the CPPFLAGS and LDFLAGS that I specified).
> This could be explained by a different compiler and flags being used
> to build a Perl XS module.
Indeed, this is the problem. The configure script and the Makefile ought to
use $CC that was provided to the configure script, not something else.
(I'm speaking from experience: In GNU clisp, for some time, I was passing
different CFLAGS value down to a specific subdirectory, and this produced
endless problems. A different CC value is even worse, because it may end
up creating .o files of a different ABI.)
In the GNU build system, the person who configures does not specify an
ABI (and allow you the choice to pick a compiler for that ABI). No, the
person who configures specifies a compiler, and you must stick to that
ABI. If libperl is built against a different ABI, your only options are
- to ignore it and not build the XS parser module, or
- to abort the configuration with an error message such as "libperl
found is not compatible with ABI implied by $CC $LDFLAGS".
FYI, for the determination of the ABI from $CC $LDFLAGS there is a
gnulib module: 'host-cpu-c-abi'.
Bruno
- Re: [platform-testers] texinfo-6.5.90 pretest on AIX, (continued)
Re: [platform-testers] texinfo-6.5.90 pretest on Mac OS X, Bruno Haible, 2019/01/04
Re: [platform-testers] texinfo-6.5.90 pretest on Solaris 10, Bruno Haible, 2019/01/04
Re: [platform-testers] texinfo-6.5.90 pretest on Solaris 10, Bruno Haible, 2019/01/18
Re: [platform-testers] texinfo-6.5.90 pretest on older CentOS, Bruno Haible, 2019/01/04
Re: texinfo-6.5.90 pretest, Andreas Schwab, 2019/01/11