bug-texinfo
[Top][All Lists]
Advanced

[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




reply via email to

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