macosx linking fails: _freea referenced from: _rpl_realpath

macosx linking fails: _freea referenced from: _rpl_realpath

[Sam Steingold]

Hi,
I get this error when linking Emacs:

--8<---------------cut here---------------start------------->8---
  CCLD     temacs
Undefined symbols for architecture x86_64:
  "_freea", referenced from:
      _rpl_realpath in libgnu.a(canonicalize-lgpl.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [temacs] Error 1
--8<---------------cut here---------------end--------------->8---

I also reported this as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36356
(https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-06/msg01229.html)

Since this involves libgnu, I was wondering if someone here might have
an insight.

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://americancensorship.org http://mideasttruth.com
XML is like violence. If it doesn't solve the problem, use more.

Re: macosx linking fails: _freea referenced from: _rpl_realpath

[Bruno Haible]

Sam Steingold wrote:
> I get this error when linking Emacs:
> 
> --8<---------------cut here---------------start------------->8---
>   CCLD     temacs
> Undefined symbols for architecture x86_64:
>   "_freea", referenced from:
>       _rpl_realpath in libgnu.a(canonicalize-lgpl.o)
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
> make[1]: *** [temacs] Error 1
> --8<---------------cut here---------------end--------------->8---
> 
> I also reported this as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36356
> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-06/msg01229.html)

1) After your latest "git pull" from emacs, have you done a "make distclean"
   followed by a reconfiguration?

If you don't remember: Does the issue persist after a "make distclean"
followed by a reconfiguration?

2) Which symbols does
  nm lib/malloca.o
show? If, as I would expect, it lists '_mmalloca' but not '_freea', it means
that the macro HAVE_ALLOCA was defined in the compilation unit
canonicalize-lgpl.c but not defined in the compilation unit malloca.c.
Can you investigate why this is so? (Where is HAVE_ALLOCA defined? In config.h,
I would guess. It is undefined somewhere? I would guess no. What are the
preprocessor symbols that are defined [use "$CC -E -dM"] in the
compilation unit canonicalize-lgpl.c, versus the compilation unit malloca.c?

Bruno

Re: macosx linking fails: _freea referenced from: _rpl_realpath

[Sam Steingold]

> * Bruno Haible <oehab@pyvfc.bet> [2019-06-25 17:00:58 +0200]:
>
> Sam Steingold wrote:
>> I get this error when linking Emacs:
>> 
>> --8<---------------cut here---------------start------------->8---
>>   CCLD     temacs
>> Undefined symbols for architecture x86_64:
>>   "_freea", referenced from:
>>       _rpl_realpath in libgnu.a(canonicalize-lgpl.o)
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>> make[1]: *** [temacs] Error 1
>> --8<---------------cut here---------------end--------------->8---
>> 
>> I also reported this as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36356
>> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-06/msg01229.html)
>
> 1) After your latest "git pull" from emacs, have you done a "make distclean"
>    followed by a reconfiguration?

no, I did "make bootstrap" which re-runs configure

> If you don't remember: Does the issue persist after a "make distclean"
> followed by a reconfiguration?

yes, I just did "make distclean; ../configure ...; make bootstrap" and
got the above error.

> 2) Which symbols does
>   nm lib/malloca.o
> show?

--8<---------------cut here---------------start------------->8---
$ find . -name \*alloc\*.o
./lib/allocator.o
./src/alloc.o
$ nm ./lib/allocator.o
                 U _free
                 U _malloc
                 U _realloc
0000000000000000 S _stdlib_allocator
--8<---------------cut here---------------end--------------->8---



> If, as I would expect, it lists '_mmalloca' but not '_freea', it means
> that the macro HAVE_ALLOCA was defined in the compilation unit
> canonicalize-lgpl.c but not defined in the compilation unit malloca.c.
> Can you investigate why this is so? (Where is HAVE_ALLOCA defined? In
> config.h, I would guess. It is undefined somewhere? I would guess no.

right:
--8<---------------cut here---------------start------------->8---
./src/config.h:#define HAVE_ALLOCA 1
./src/config.h:#define HAVE_ALLOCA_H 1
--8<---------------cut here---------------end--------------->8---

> What are the preprocessor symbols that are defined [use "$CC -E
> -dM"] in the compilation unit canonicalize-lgpl.c, versus the
> compilation unit malloca.c?

--8<---------------cut here---------------start------------->8---
$ gcc -Isrc -I../src -E -dM ../lib/malloca.c > m
$ gcc -Isrc -I../src -E -dM ../lib/canonicalize-lgpl.c > c
$ diff -u m c|grep -i ^[-+].*alloc
+#define MAXALLOCSAVE (2 * CLBYTES)
+#define _PC_ALLOC_SIZE_MIN 16
$ diff -u m c|grep -i ^[-+].*free
<empty>
--8<---------------cut here---------------end--------------->8---

However, I see no malloca.o in lib (where canonicalize-lgpl.o is found)
I wonder if there is some magic autoconf place where canonicalize-lgpl
is mentioned but malloca is not.

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://think-israel.org http://www.memritv.org https://jihadwatch.org
He who laughs last thinks slowest.

Re: macosx linking fails: _freea referenced from: _rpl_realpath

[Bruno Haible]

Sam Steingold wrote:
> > If you don't remember: Does the issue persist after a "make distclean"
> > followed by a reconfiguration?
> 
> yes, I just did "make distclean; ../configure ...; make bootstrap" and
> got the above error.

OK.

> > 2) Which symbols does
> >   nm lib/malloca.o
> > show?
> 
> --8<---------------cut here---------------start------------->8---
> $ find . -name \*alloc\*.o
> ./lib/allocator.o
> ./src/alloc.o

Oh, this is surprising.

The compilation of malloca.c should be enabled here:


ifeq (,$(OMIT_GNULIB_MODULE_malloca))

ifneq (,$(gl_GNULIB_ENABLED_malloca))
libgnu_a_SOURCES += malloca.c

endif
EXTRA_DIST += malloca.h

endif


1) Can you please verify that nothing defines the Makefile macro
   OMIT_GNULIB_MODULE_malloca in your build?
2) What are the values of HAVE_CANONICALIZE_FILE_NAME and
   REPLACE_CANONICALIZE_FILE_NAME in config.status?
3) I'd need to see why gl_GNULIB_ENABLED_malloca is not getting set.
   Can you please run "make distclean", rerun configure with shell tracing:
     sh -x ./configure ... 2>&1 |tee config.shlog
   and attach the generated config.shlog file as well as config.log, config.status,
   and the configure script (in compressed form)?
   I hope I can understand the cause by looking at this log.
4) Also, it would help to know why the linker is not complaining about
   a missing '_mmalloca' symbol.
   $ nm lib/canonicalize-lgpl.o | grep malloca
   $ for f in `find . -name '*.o'`; do echo $f ; nm $f | grep malloca ; done

Bruno

Re: macosx linking fails: _freea referenced from: _rpl_realpath

[Sam Steingold]

> * Bruno Haible <oehab@pyvfc.bet> [2019-06-25 19:11:03 +0200]:
>
>> $ find . -name \*alloc\*.o
>> ./lib/allocator.o
>> ./src/alloc.o
>
> Oh, this is surprising.

aha!

I re-run gnulib-tool and it fixed it.
(alas, emacs maintainers pushed the changes before me ;-)

thanks and sorry about bothering you!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1671
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://iris.org.il http://no2bds.org http://mideasttruth.com
Do not worry about which side your bread is buttered on: you eat BOTH sides.

Re: macosx linking fails: _freea referenced from: _rpl_realpath

[Bruno Haible]

Sam Steingold wrote:
> I re-run gnulib-tool and it fixed it.
> (alas, emacs maintainers pushed the changes before me ;-)

So, what was the cause? What can be done to avoid similar errors in the future?

When I look at the history of emacs/lib/gnulib.mk.in, it looks like
(1) there was a change that added dependencies to canonicalize-lgpl and malloca
    yesterday, but it did NOT add the variable gl_GNULIB_ENABLED_malloca.
(2) Paul regenerated it again, which added the variable gl_GNULIB_ENABLED_malloca.

(1) apparently introduced the problem that Sam reported. (2) fixed it.

Daniel, do you have an idea why your tooling created an incomplete
emacs/lib/gnulib.mk.in, that you then checked in?

Bruno