bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Alexandre Duret-Lutz <adl@lrde.epita.fr>
To: bug-gnulib <bug-gnulib@gnu.org>
Subject: cannot figure out how to work with GNULIB_NAMESPACE without warnings
Date: Wed, 13 Jan 2021 17:54:18 +0100	[thread overview]
Message-ID: <87turkvkud.fsf@lrde.epita.fr> (raw)

Hi

Testing my updated version of gnulib (as specified yesterday
in https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00177.html)

I ran into the following linking issue, which I did not have 8 months ago.

/usr/bin/i686-w64-mingw32-ld: misc/.libs/libmisc.a(satsolver.o): in function `ZNSt13basic_filebufIcSt11char_traitsIcEED4Ev':
/usr/lib/gcc/i686-w64-mingw32/10-posix/include/c++/fstream:249: undefined reference to `std::basic_filebuf<char, std::char_traits<char> >::rpl_close()'
collect2: error: ld returned 1 exit status

[That's a cross compilation for MinGW, obviously.]

Since this seems to the kind of error documented on
https://www.gnu.org/software/gnulib/manual/html_node/A-C_002b_002b-namespace-for-gnulib.html
I tried to do

   AC_DEFINE_UNQUOTED([GNULIB_NAMESPACE], [gnulib])

(knowing that I would then have to track down the use of many replaced
function, and prefix them with gnulib::)

However then compilation failed with a message telling me that a
system-installed header should use gnulib::vsnprintf instead
of std::vsnprintf!

libtool: compile:  clang++ -Qunused-arguments -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -I../../buddy/src -I../../lib -I../../lib -W -Wall -Werror -Wint-to-void-pointer-cast -Wcast-align -Wpointer-arith -Wwrite-strings -Wcast-qual -DXTSTRINGDEFINES -Wdocumentation -Wmissing-declarations -Woverloaded-virtual -Wmisleading-indentation -Wimplicit-fallthrough -Wnull-dereference -Wsuggest-override -Wpedantic -fvisibility=hidden -fvisibility-inlines-hidden -DSPOT_BUILD -std=c++20 -g -O -MT clz.lo -MD -MP -MF .deps/clz.Tpo -c clz.cc  -fPIC -DPIC -o .libs/clz.o
In file included from bitvect.cc:23:
In file included from ../../spot/misc/bitvect.hh:22:
In file included from ../../spot/misc/common.hh:21:
In file included from /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/stdexcept:39:
In file included from /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/string:55:
/usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/basic_string.h:6652:50: error: The symbol ::vsnprintf refers to the system function. Use gnulib::vsnprintf instead. [-Werror,-Wuser-defined-warnings]
    return __gnu_cxx::__to_xstring<string>(&std::vsnprintf, __n,
                                                 ^
../../lib/stdio.h:2104:1: note: from 'diagnose_if' attribute on 'vsnprintf':
_GL_CXXALIASWARN (vsnprintf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:382:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:384:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:389:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:553:19: note: expanded from macro '_GL_WARN_ON_USE'
  __attribute__ ((__diagnose_if__ (1, message, "warning")))
                  ^                ~

This was clang++ 11.0.0 on Arch linux.


Since the original issue I have is with rpl_close(), and that I don't
really care about the issues it fixes, I've tried to use "gnulib-tool
--avoid=close" but in that case I get "#define close _close", which does
not help either.


Any clue ?
-- 
Alexandre Duret-Lutz


             reply	other threads:[~2021-01-13 16:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 16:54 Alexandre Duret-Lutz [this message]
2021-01-14  0:58 ` cannot figure out how to work with GNULIB_NAMESPACE without warnings Bruno Haible
2021-01-14 10:35   ` Alexandre Duret-Lutz
2021-01-14 13:43     ` clang++ hard failure with GNULIB_NAMESPACE Alexandre Duret-Lutz
2021-01-15  9:51       ` Bruno Haible
2021-01-15 12:19         ` Alexandre Duret-Lutz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87turkvkud.fsf@lrde.epita.fr \
    --to=adl@lrde.epita.fr \
    --cc=bug-gnulib@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).