search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.91k stars 542 forks source link

locale.c:1182: undefined reference to `libintl_textdomain' #18467

Open noloader opened 3 years ago

noloader commented 3 years ago

Description I'm working on Fedora 33, x86_64. I'm trying to build Perl 5.32 from sources. Fedora is different than Ubuntu. Fedora prefers lib64/ for its libdir, while Ubuntu prefers lib/ for its libdir.

The build is failing with:

/bin/cc -L/home/jwalton/ok2delete/lib64 -Wl,-R,/../lib64 -Wl,-R,/home/jwalton/ok2delete/lib64 -Wl,--enable-new-dtags -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,origin -fstack-protector-strong -L/opt/local/lib -o miniperl \
    opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lcrypt -lutil -lc 
/bin/ld: locale.o: in function `S_emulate_setlocale':
/home/jwalton/Build-Scripts/perl-5.32.0/locale.c:1182: undefined reference to `libintl_textdomain'
/bin/ld: /home/jwalton/Build-Scripts/perl-5.32.0/locale.c:1182: undefined reference to `libintl_textdomain'
collect2: error: ld returned 1 exit status
gmake: *** [makefile:363: lib/buildcustomize.pl] Error 1

It appears Perl's miniperl is not linking with -lintl like it should.

Steps to Reproduce I wish I could provide a one-liner to reproduce the issue.

I built and installed all of Perl's dependencies, including an updated GetText. Headers are located at /home/jwalton/ok2delete/include, and libraries are located at /home/jwalton/ok2delete/lib64.

Then I built Perl with the following command:

# Strip duplicate, leading and trailing colons
LD_LIBRARY_PATH=$(echo "$INSTX_LIBDIR:$LD_LIBRARY_PATH" | tr -s ':' | sed -e 's/^:\(.*\)/\1/' | sed -e 's/:$//g')
export LD_LIBRARY_PATH

# Use our up-to-date and hardened libraries.
# See http://www.linuxfromscratch.org/lfs/view/development/chapter08/perl.html
export BUILD_ZLIB=0 BUILD_BZIP2=0

    CC="${CC}" \
    CXX="${CXX}" \
    PKGCONFIG="${INSTX_PKGCONFIG}" \
    CPPFLAGS="${INSTX_CPPFLAGS}" \
    ASFLAGS="${INSTX_ASFLAGS}" \
    CFLAGS="${INSTX_CFLAGS}" \
    CXXFLAGS="${INSTX_CXXFLAGS}" \
    LDFLAGS="${INSTX_LDFLAGS}" \
    LDLIBS="${INSTX_LDLIBS}" \
    LIBS="${INSTX_LDLIBS}" \
./Configure -des \
    -Dprefix="${INSTX_PREFIX}" \
    -Dlibdir="${INSTX_LIBDIR}" \
    -Dpkgconfig="${INSTX_PKGCONFIG}" \
    -Dcc="${CC}" \
    -Dcxx="${CXX}" \
    -Acppflags="${INSTX_CPPFLAGS}" \
    -Aasflags="${INSTX_ASFLAGS}" \
    -Accflags="${INSTX_CFLAGS}  ${INSTX_CPPFLAGS}" \
    -Acxxflags="${INSTX_CXXFLAGS}  ${INSTX_CPPFLAGS}" \
    -Aldflags="${INSTX_LDFLAGS}" \
    -Aldlibs="${INSTX_LDLIBS}" \
    -Duseshrplib \
    -Dusethreads \
    -Dextras="FindBin Text Util Term Test HTTP"

The INSTX_* variables are as follows. Variables like CPPFLAGS and CFLAGS are internally held in INSTX_CPPFLAGS and INSTX_CFLAGS, etc. I keep them in INSTX_* variables so other programs do not whack them.

  INSTX_BITNESS: 64-bits
   INSTX_PREFIX: /home/jwalton/ok2delete
   INSTX_LIBDIR: /home/jwalton/ok2delete/lib64
    INSTX_OPATH: '$ORIGIN/../lib64'
    INSTX_RPATH: /home/jwalton/ok2delete/lib64

 AUTOCONF_BUILD: x86_64-pc-linux-gnu
PKG_CONFIG_PATH: /home/jwalton/ok2delete/lib64/pkgconfig
       CPPFLAGS: -I/home/jwalton/ok2delete/include -DNDEBUG
        ASFLAGS: -Wa,--noexecstack
         CFLAGS: -g2 -O2 -march=native -fPIC -pthread
       CXXFLAGS: -g2 -O2 -march=native -fPIC -pthread
        LDFLAGS: -L/home/jwalton/ok2delete/lib64 -Wl,-R,'$ORIGIN/../lib64' -Wl,-R,/home/jwalton/ok2delete/lib64 -Wl,--enable-new-dtags -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,origin
         LDLIBS: -ldl -lpthread

   CC: /bin/cc
  CXX: /bin/g++

I don't see any log files to provide for you:

perl-5.32.0$ find . -name '*.log'
perl-5.32.0$

Perl configuration Unfortunately I don't have a configuration yet:

perl-5.32.0$ LD_LIBRARY_PATH=".:./lib" PERL5LIB=./lib ./perl -V
-bash: ./perl: No such file or directory
jkeenan commented 3 years ago

Description I'm working on Fedora 33, x86_64. I'm trying to build Perl 5.32 from sources. Fedora is different than Ubuntu. Fedora prefers lib64/ for its libdir, while Ubuntu prefers lib/ for its libdir.

The build is failing with:

/bin/cc -L/home/jwalton/ok2delete/lib64 -Wl,-R,/../lib64 -Wl,-R,/home/jwalton/ok2delete/lib64 -Wl,--enable-new-dtags -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,origin -fstack-protector-strong -L/opt/local/lib -o miniperl \
    opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lcrypt -lutil -lc 
/bin/ld: locale.o: in function `S_emulate_setlocale':
/home/jwalton/Build-Scripts/perl-5.32.0/locale.c:1182: undefined reference to `libintl_textdomain'
/bin/ld: /home/jwalton/Build-Scripts/perl-5.32.0/locale.c:1182: undefined reference to `libintl_textdomain'
collect2: error: ld returned 1 exit status
gmake: *** [makefile:363: lib/buildcustomize.pl] Error 1

It appears Perl's miniperl is not linking with -lintl like it should.

I appreciate the detail you have provided in this report. However, from a debugging point of view that can be somewhat overwhelming, especially given the complexity of your configuration.

Could I ask: Suppose you were to simply unwrap a perl-5.32.0 tarball, change into the build directory and say:

$ sh ./Configure -des -Dusedevel -Duseithreads 
$ make minitest_prep

Do you get that far? Next, what happens when you say:

$ make minitest

And finally, what happens when you then say:

$ make test_prep

Proceeding from a very simple configuration might shed light on the step that goes wrong. It might also indicate if this is something that is Fedora-specific.

Thank you very much. Jim Keenan

tonycoz commented 3 years ago

Description I'm working on Fedora 33, x86_64. I'm trying to build Perl 5.32 from sources. Fedora is different than Ubuntu. Fedora prefers lib64/ for its libdir, while Ubuntu prefers lib/ for its libdir.

The build is failing with:

/bin/cc -L/home/jwalton/ok2delete/lib64 -Wl,-R,/../lib64 -Wl,-R,/home/jwalton/ok2delete/lib64 -Wl,--enable-new-dtags -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,-z,origin -fstack-protector-strong -L/opt/local/lib -o miniperl \
    opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lcrypt -lutil -lc 
/bin/ld: locale.o: in function `S_emulate_setlocale':
/home/jwalton/Build-Scripts/perl-5.32.0/locale.c:1182: undefined reference to `libintl_textdomain'
/bin/ld: /home/jwalton/Build-Scripts/perl-5.32.0/locale.c:1182: undefined reference to `libintl_textdomain'
collect2: error: ld returned 1 exit status
gmake: *** [makefile:363: lib/buildcustomize.pl] Error 1

It appears Perl's miniperl is not linking with -lintl like it should.

Is perl using the glibc libintl.h or the gettext libintl.h?

https://gcc.gnu.org/legacy-ml/gcc-help/2014-09/msg00022.html

I believe the intent here to call the glibc textdomain() to work around a glibc bug, not the gettext() version.

noloader commented 3 years ago

Thanks @jkeenan and @tonycoz,

Is perl using the glibc libintl.h or the gettext libintl.h?

https://gcc.gnu.org/legacy-ml/gcc-help/2014-09/msg00022.html

I believe the intent here to call the glibc textdomain() to work around a glibc bug, not the gettext() version.

There's a new GetText built and installed in $HOME/ok2delete. It is the latest version of GetText - 0.21.0.

I have to avoid glibc versions of functions because of past bugs. I can build/install an updated GetText. I cannot build/install an updated Glibc. And on systems like OS X and Solaris there is no Glibc.

noloader commented 3 years ago

I added -lintl to LIBS, LDLIBS, -Alibs and -Aldlibs. I'm stills eeing the problem.

What more do I need to do to get Perl to use my damn flags?

    CC="${CC}" \
    CXX="${CXX}" \
    PKGCONFIG="${INSTX_PKGCONFIG}" \
    CPPFLAGS="${INSTX_CPPFLAGS}" \
    ASFLAGS="${INSTX_ASFLAGS}" \
    CFLAGS="${INSTX_CFLAGS}" \
    CXXFLAGS="${INSTX_CXXFLAGS}" \
    LDFLAGS="${INSTX_LDFLAGS}" \
    LDLIBS="-lintl ${INSTX_LDLIBS}" \
    LIBS="-lintl ${INSTX_LDLIBS}" \
./Configure -des \
    -Dprefix="${INSTX_PREFIX}" \
    -Dlibdir="${INSTX_LIBDIR}" \
    -Dpkgconfig="${INSTX_PKGCONFIG}" \
    -Dcc="${CC}" \
    -Dcxx="${CXX}" \
    -Acppflags="${INSTX_CPPFLAGS}" \
    -Aasflags="${INSTX_ASFLAGS}" \
    -Accflags="${INSTX_CPPFLAGS} ${INSTX_CFLAGS}" \
    -Acxxflags="${INSTX_CPPFLAGS} ${INSTX_CXXFLAGS}" \
    -Aldflags="${INSTX_LDFLAGS}" \
    -Aldlibs="-lintl ${INSTX_LDLIBS}" \
    -Alibs="-lintl ${INSTX_LDLIBS}" \
    -Duseshrplib \
    -Dusethreads \
    -Dextras="FindBin Text Util ExtUtils Term Test HTTP"
Leont commented 3 years ago

Where do those things come from? Are you assuming our Configure is autoconf? I don't think any of those environmental flags do anything, and half of those config variables don't exist; in particular pkgconfig, ldlibs and libdir don't.

noloader commented 3 years ago

Thanks @Leont,

Where do those things come from?

The notes with my scripts don't include the information. I don't recall where I read about them.

Are you assuming our Configure is autoconf?

No, using using make. I supply both to ensure the flags are used. For example, Perl configure can use -Aldlibs, or the makefile generated by Perl can use LDLIBS. It does not matter to me how they get picked up as long as they are used.

I don't think any of those environmental flags do anything, and half of those config variables don't exist; in particular pkgconfig, ldlibs and libdir don't.

Sigh... I don't get a configuration warning or error using them.

Ok, let's go back to the beginning. Where does Perl publish the mapping of implicit variables to Perl options? The variables are listed in GNU Make manual in the section Implicit Variables. Here is the subset of the ones I set:

The makefile is supposed to use LDLIBS. Most projects use Autotool's LIBS, so I set them both. There is no harm in listing a library twice.

doughera88 commented 3 years ago

Are you assuming our Configure is autoconf?

No, using using make. I supply both to ensure the flags are used. For example, Perl configure can use -Aldlibs, or the makefile generated by Perl can use LDLIBS. It does not matter to me how they get picked up as long as they are used.

It does matter to perl. Perl's Configure needs to know the various flags in order to perform various configuration tests. The flags given to Configure and those used by the Makefile ought to be consistent. Hence you've got to correctly pass them to Configure.

I don't think any of those environmental flags do anything, and half of those config variables don't exist; in particular pkgconfig, ldlibs and libdir don't.

Sigh... I don't get a configuration warning or error using them.

I don't think Configure ought to warn about variables that it doesn't use. You might well have them set for some other legitimate purpose.

Ok, let's go back to the beginning. Where does Perl publish the mapping of implicit variables to Perl options?

Many of the Configure variables are documented in the INSTALL document. See the section starting =head2 Common Configure options See the Porting/Glossary file for a complete list of Configure variables you can set and their definitions. Since Configure is not autoconf, these variables are different from the autoconf ones, and there might not always be an exact mapping.

Meanwhile, you can get a summary of your existing configuration by running the ./myconfig shell script in the top directory of the perl distribution.

ffontaine commented 3 years ago

We have the same build failures with perl 5.32.1 on buildroot with uclibc and NLS support, it can fixed by passing -lintl to Configure through -Dldflags

Tux commented 3 years ago

Should -lintl be added to libswanted in Configure?

khwilliamson commented 3 years ago

On 2/22/21 1:06 AM, H.Merijn Brand wrote:

Should |-lintl| be added to libswanted in |Configure|?

I don't know, but the additional information is that this is needed only because of a glibc bug, reported and confirmed, but with no further activity: [perl #134264]

Perhaps people finding this inconvenient have some "in" to get attention paid to the root cause problem

https://sourceware.org/bugzilla/show_bug.cgi?id=24936

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Perl/perl5/issues/18467#issuecomment-783176913, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2DH2SAQCJYHWKGQUKATDTAIGAPANCNFSM4V4ZSM2A.

doughera88 commented 3 years ago

On Tue, Feb 23, 2021 at 04:58:51PM -0800, Karl Williamson wrote:

On 2/22/21 1:06 AM, H.Merijn Brand wrote:

Should |-lintl| be added to libswanted in |Configure|?

I don't know, but the additional information is that this is needed only because of a glibc bug, reported and confirmed, but with no further activity: [perl #134264]

I don't know either. Is it ever wrong to include -lintl? Does the version there also have (possibly different) bugs?

One ambitious approach would be to introduce a Configure test for the bug, and then if the bug is found, try adding in -lintl to the front of libswanted.

More immediately, the original poster can force the issue with the

-A prepend:libswanted='intl '

option to Configure. (The trailing space is essential.)

-- Andy Dougherty doughera@lafayette.edu

barracuda156 commented 2 weeks ago

This is still broken in perl 5.32 and later.

On Linux riscv64:

/usr/bin/clang -fstack-protector-strong -L/opt/local/lib -o miniperl \
    opmini.o perlmini.o  gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o caretx.o dquote.o time64.o  miniperlmain.o  -lpthread -ldl -lm -lutil -lc 
/usr/bin/riscv64-pine64-linux-ld: locale.o: in function `.LBB1_125':
locale.c:(.text+0x83c): undefined reference to `libintl_textdomain'
/usr/bin/riscv64-pine64-linux-ld: locale.c:(.text+0x844): undefined reference to `libintl_textdomain'
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [makefile:363: lib/buildcustomize.pl] Error 1
388 warnings generated.
make: Target 'all' not remade because of errors.
make: Leaving directory '/opt/local/var/macports/build/_home_svacchanda_lnxports_lang_perl5/perl5.32/work/perl-5.32.1'
Command failed:  cd "/opt/local/var/macports/build/_home_svacchanda_lnxports_lang_perl5/perl5.32/work/perl-5.32.1" && /usr/bin/make -j4 -w all -w -k 
Exit code: 2