bug-gnulib
[Top][All Lists]
Advanced

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

Re: macosx linking fails: _freea referenced from: _rpl_realpath


From: Sam Steingold
Subject: Re: macosx linking fails: _freea referenced from: _rpl_realpath
Date: Tue, 25 Jun 2019 12:19:12 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (darwin)

> * Bruno Haible <address@hidden> [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.



reply via email to

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