bug-gnulib
[Top][All Lists]
Advanced

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

Re: rpl_free undefined


From: Bruno Haible
Subject: Re: rpl_free undefined
Date: Mon, 02 May 2022 03:02:20 +0200

Reuben Thomas wrote:
> Check out https://github.com/rrthomas/libpaper.git commit 8fe608f on MSYS
> 
> Edit bootstrap.conf to remove the posix-free module
> 
> ./bootstrap

I don't want to debug a gnulib version from more than 1 year ago, therefore
I'm using
   ./bootstrap --skip-git --gnulib-srcdir=$GNULIB_SRCDIR
(Argh. Why is this option not called --no-git, like in the other 'bootstrap'?)

Then I get an error message
  ./bootstrap: 136: eval: ./gnulib/gnulib-tool: not found
(Argh. I'm not going to debug your private 'bootstrap' variant.)

Then there is an error
  src/Makefile.am:31: error: RELOCATABLE_VIA_LD does not appear in 
AM_CONDITIONAL
that's because relocatable.m4 is not included.

=> These "how to reproduce" instructions don't work for me.

Please provide me a tarball generated with a current gnulib (today or a few
days ago), that exhibits the problem.


In any case, I can guess that your bootstrap.conf organises for two gnulib-tool
invocations. Probably as documented in
  https://www.gnu.org/software/gnulib/manual/html_node/Multiple-instances.html
The problem that you report can easily happen if
  (1) the gnulib-tool invocation for the "library" uses code that makes use
      of the free() function, without requiring 'free-posix',
  (2) the gnulib-tool invocation for "src" uses the module 'free-posix'
      (implicitly or explicitly),
  (3) the -I options for building the "library" gnulib include the build
      directory of the "src" gnulib; this is where a generated stdlib.h
      will be placed that does '#define free rpl_free'.

(1) and (2) are OK. Your workaround is in (1), by adding 'free-posix' to
the modules. But the real fix is to fix (3): Don't let the "library" gnulib
build be influenced by the "src" gnulib.

This is what I _guess_ is happening. Please provide a tarball, as described
above, so that I could confirm it. There were definitely some (big) changes
in this area in the last year; that's why I say that the tarball should be
built with a recent gnulib.

Bruno






reply via email to

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