OS X compile fails with 'Invalid function: cdr' #38

Closed
rogermarlow opened this Issue Jan 13, 2017 · 41 comments

Projects

None yet
@rogermarlow
Contributor

When building on MacOS, assuming PR #37 is applied, the build terminates as follows

4480 unused bytes follow Mach-O header
89147 pure bytes used
mv -f remacs bootstrap-emacs
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
  ELC      emacs-lisp/macroexp.elc
Invalid function: eq
make[2]: *** [emacs-lisp/macroexp.elc] Error 255
make[1]: *** [bootstrap-emacs] Error 2
make: *** [src] Error 2

eq appears to be defined in rust_src/src/strings.rs but doesn't make it in to bootstrap-emacs as a symbol

$ strings src/bootstrap-emacs | grep eq
[ not there ]

whereas stringp which is also defined in rust_src/src/strings.rs is a symbol

$ strings src/bootstrap-emacs| grep stringp
stringp
stringp
@rogermarlow
Contributor

Scrub that thought on symbols, eq is there. Try nm -mo src/bootstrap-emacs | grep [SFQ]eq

@rogermarlow
Contributor

eq implemented in PR #13 . Fetched but macOS build now broken prior to reaching the ELC emacs-lisp/macroexp.elc line so can't see if it fixes this issue.

@Wilfred
Owner
Wilfred commented Jan 14, 2017

eq being missing probably meant that you hadn't rebuilt after pulling #13. Now that we have a proper makefile, this shouldn't be an issue in future (fingers crossed).

Are you still seeing this issue when doing a clean build? Can you confirm that you have no .elc files before starting the build?

@rogermarlow
Contributor

This is on macOS, but from a clean start I now get Invalid function: car:

[ *snip* ]
mv -f remacs bootstrap-emacs
/Library/Developer/CommandLineTools/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
  ELC      emacs-lisp/macroexp.elc
Invalid function: car
make[2]: *** [emacs-lisp/macroexp.elc] Error 255
make[1]: *** [bootstrap-emacs] Error 2
make: *** [src] Error 2

How do I go about debugging that? I can see likely symbols in libremacs.a

$ nm rust_src/target/release/libremacs.a | grep car
0000000000000810 T _Fcar
0000000000000770 T _Fsetcar
0000000000003940 b __ZN55_$LT$remacs..cons..Scar$u20$as$u20$core..ops..Deref$GT$5deref11__stability4LAZY17h359f9d3f18e67075E
0000000000003920 b __ZN58_$LT$remacs..cons..Ssetcar$u20$as$u20$core..ops..Deref$GT$5deref11__stability4LAZY17h8c55925ab1e59632E

and also in the executable

$ nm src/bootstrap-emacs | grep car
00000001001d7700 T _Fcar
00000001000f0b80 T _Fcar_less_than_car
000000010011d090 T _Fcar_safe
00000001000ba170 T _Fdiscard_input
000000010013cf80 T _Fmapcar
00000001001d7660 T _Fsetcar
000000010022f390 S _Qcar_less_than_car
00000001002b1068 d _Scar_less_than_car
00000001005e4118 d _Scar_safe
00000001002aee78 d _Sdiscard_input
00000001005e75a0 d _Smapcar
00000001006757b8 b __ZN55_$LT$remacs..cons..Scar$u20$as$u20$core..ops..Deref$GT$5deref11__stability4LAZY17h359f9d3f18e67075E
0000000100675798 b __ZN58_$LT$remacs..cons..Ssetcar$u20$as$u20$core..ops..Deref$GT$5deref11__stability4LAZY17h8c55925ab1e59632E
00000001001c83d0 T _careadlinkat
00000001000580b0 T _discard_menu_items
00000001000c2bb0 T _discard_mouse_events
00000001000d30b0 T _discard_tty_input
0000000100010b60 T _frames_discard_buffer
000000010013cce0 t _mapcar1
0000000100119660 t _mark_discard_killed_buffers
00000001000b3cf0 T _xcar_addr
$

and if I try to just run the exe

$ ./src/bootstrap-emacs
Invalid function: car
$

where do I go from here?

@Wilfred
Owner
Wilfred commented Jan 14, 2017

Weird. As a sanity check, could you put a println!("calling rust_init_syms"); inside rust_init_syms and see when it gets called? It should get called during the temacs dumping process.

@Wilfred
Owner
Wilfred commented Jan 14, 2017 edited

For what it's worth, Invalid function: foo is a result of calling signal with 'invalid-function (which is Qinvalid_function at the C level):

M-x ielm
ELISP> (signal 'invalid-function (cons 'foo nil))
*** Eval error ***  Invalid function: foo
@Wilfred
Owner
Wilfred commented Jan 14, 2017

I imagine something is calling xsignal1 (Qinvalid_function, original_fun);.

If you try to run bootstrap_emacs with gdb, you should be able to get a backtrace. Something like:

$ gdb src/remacs
Reading symbols from src/remacs...done.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/wilfred/projects/remacs/src/remacs.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) b xsignal1
Breakpoint 1 at 0x55c930: file eval.c, line 1597.
(gdb) run -q

Thread 1 "remacs" hit Breakpoint 1, xsignal1 ...
(gdb) bt
@rogermarlow
Contributor
$ git diff
diff --git a/rust_src/src/lib.rs b/rust_src/src/lib.rs
index a51a0a8..b0e231a 100644
--- a/rust_src/src/lib.rs
+++ b/rust_src/src/lib.rs
@@ -39,6 +39,7 @@ extern "C" {
 #[no_mangle]
 pub extern "C" fn rust_init_syms() {
     unsafe {
+        println!("calling rust_init_syms");
         defsubr(&*atom::Satom);
         defsubr(&*math::Smod);
         defsubr(&*math::Splus);
$ make clean && make
[*snip*]
mv -f remacs bootstrap-emacs
/Library/Developer/CommandLineTools/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
  ELC      emacs-lisp/macroexp.elc
Invalid function: car
make[2]: *** [emacs-lisp/macroexp.elc] Error 255
make[1]: *** [bootstrap-emacs] Error 2
make: *** [src] Error 2
$
@rogermarlow
Contributor

Results of breaking at xsignal1

Thread 2 hit Breakpoint 1, xsignal1 (error_symbol=26208, arg=18378304) at eval.c:1598
1598	  xsignal (error_symbol, list1 (arg));
(gdb) bt
#0  xsignal1 (error_symbol=26208, arg=18378304) at eval.c:1598
#1  0x00000001001316d9 in eval_sub (form=<optimized out>) at eval.c:2223
#2  0x00000001001319f1 in Fsetq (args=<optimized out>) at eval.c:502
#3  0x00000001001313cf in eval_sub (form=<optimized out>) at eval.c:2125
#4  0x0000000100132959 in Fprogn (body=<optimized out>) at eval.c:431
#5  Fwhile (args=<optimized out>) at eval.c:971
#6  0x00000001001313cf in eval_sub (form=<optimized out>) at eval.c:2125
#7  0x0000000100132829 in Fprogn (body=26208) at eval.c:431
#8  Flet (args=4417922211) at eval.c:952
#9  0x00000001001313cf in eval_sub (form=<optimized out>) at eval.c:2125
#10 0x00000001001317e9 in Fprogn (body=26208) at eval.c:431
#11 Fif (args=<optimized out>) at eval.c:389
#12 0x00000001001313cf in eval_sub (form=<optimized out>) at eval.c:2125
#13 0x0000000100135399 in Fprogn (body=<optimized out>) at eval.c:431
#14 funcall_lambda (fun=<optimized out>, nargs=<optimized out>, arg_vector=0x7fff5fbfeee0) at eval.c:2922
#15 0x0000000100133fd4 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=4) at eval.c:2800
#16 0x00000001001312d9 in eval_sub (form=<optimized out>) at eval.c:2217
#17 0x0000000100133e26 in Feval (form=11, lexical=<optimized out>) at eval.c:1994
#18 0x00000001001331e6 in internal_condition_case (bfun=0x6660, handlers=<optimized out>, hfun=0xb) at eval.c:1315
#19 0x00000001000c97dd in top_level_1 (ignore=<optimized out>) at keyboard.c:1129
#20 0x0000000100132d46 in internal_catch (tag=<optimized out>, func=0x6660, arg=11) at eval.c:1080
#21 0x00000001000b9aef in command_loop () at keyboard.c:1090
#22 0x00000001000b9a11 in recursive_edit_1 () at keyboard.c:697
#23 0x00000001000b9c3a in Frecursive_edit () at keyboard.c:768
#24 0x00000001000b8938 in main (argc=<error reading variable: Cannot access memory at address 0x0>, argv=<optimized out>) at emacs.c:1629
@chrisbarrett

As a (probably useless) datapoint, on OS X 10.11 I can neither build master here, nor the upstream Emacs repo @ 25.1.

@rogermarlow
Contributor

@chrisbarrett where is it failing? Can you put relevant (failing) part of the build log here?

@chrisbarrett

Same thing as you I think.

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
  ELC      uvs.elc
Invalid function: car
make[2]: *** [uvs.elc] Error 255
make[1]: *** [macuvs.h] Error 2
make: *** [src] Error 2
@rogermarlow
Contributor

@chrisbarrett yep that's the same. By the time we get to this point in the build the Emacs Lisp compiler is built and running, but the symbols defined in the Rust code don't seem to have made it in there. Why would that only happen on MacOS? Wilfred mentioned rust_init_syms and following his advice I put in a basic println! which we don't see, so I reckon it's not being called. Seems like that would explain why it doesn't then know about things like car or eq. @Wilfred how does remacs get its symbols into the interpreter alongside the C ones? And could there be something in the configure on Macs that stops it happening? Help!

@Wilfred
Owner
Wilfred commented Jan 16, 2017 edited

@Wilfred how does remacs get its symbols into the interpreter alongside the C ones?

It's during the temacs execution, before the dump. Perhaps it's possible that rust_init_syms was earlier in the compile log than you were expecting, and so you couldn't see it in the noise?

$ git diff
diff --git i/rust_src/src/lib.rs w/rust_src/src/lib.rs
index 3f6ff95e71..e28021faf2 100644
--- i/rust_src/src/lib.rs
+++ w/rust_src/src/lib.rs
@@ -49,6 +49,7 @@ extern "C" {
 
 #[no_mangle]
 pub extern "C" fn rust_init_syms() {
+    println!("calling rust_init_syms");
     unsafe {
         defsubr(&*lists::Satom);
         defsubr(&*lists::Slistp);

Deleting all my .elc files and then running make gives me (edited for clarity):

  ... compiling lots of C
  CC       lastfile.o
  CC       gmalloc.o
  GEN      ../../etc/charsets/JISX2131.map
  GEN      charsets.stamp
  CCLD     temacs
./temacs --batch  --load loadup bootstrap
calling rust_init_syms <=== here!
Loading loadup.el (source)...
Using load-path (/home/wilfred/projects/remacs/lisp /home/wilfred/projects/remacs/lisp/emacs-lisp /home/wilfred/projects/remacs/lisp/language /home/wilfred/projects/remacs/lisp/international /home/wilfred/projects/remacs/lisp/textmodes /home/wilfred/projects/remacs/lisp/vc)
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
... loading lots of files
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name emacs
22032288 of 33554432 static heap bytes used
93218 pure bytes used
mv -f remacs bootstrap-emacs
make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[2]: Entering directory '/home/wilfred/projects/remacs/lisp'
Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
  GEN      loaddefs.el
  ELC      emacs-lisp/macroexp.elc
  ... byte-compiling lots of .el files

I will try and grab a Mac in the next few days and have a poke around too.

@Wilfred Wilfred added a commit that referenced this issue Jan 16, 2017
@Wilfred Build on OS X too (wip)
Related: #38
51290d4
@rogermarlow
Contributor

Yes, you're right. Needed a bigger banner! :-)

  CCLD     temacs
/usr/local/bin/gmkdir -p ../etc
/Library/Developer/CommandLineTools/usr/bin/make -C ../lisp update-subdirs
./temacs --batch --load loadup bootstrap
>>>>>>>>>>>>>>>>>>rust_init_syms called<<<<<<<<<<<<<<<<<<<<<<<
Loading loadup.el (source)...

And that means I'm really stuck :-)

@c-nixon c-nixon added a commit to c-nixon/remacs that referenced this issue Jan 17, 2017
@Wilfred @c-nixon + c-nixon Build on OS X too (wip)
Related: #38
88ba32a
@c-nixon
Collaborator
c-nixon commented Jan 17, 2017 edited

You could try rebuilding with ./configure --enable-profiling --enable-rust-debug LDFLAGS="-Wl,--no-undefined" to get a better backtrace and make sure all the symbols are actually populated.

@c-nixon
Collaborator
c-nixon commented Jan 17, 2017

It might be -Wl,-undefined,error on mac...

@travisbhartwell

I've got a similar error here as well, with the latest master as well as the osx_build_on_travis branch. Except mine claims that cdr is the invalid function.

I'm on macOS 10.11 (El Capitan).

I built it from a recently pulled master like this:

( make clean && git clean -fdx && ./autogen.sh && ./configure --enable-rust-debug --without-makeinfo && make ) > ~/tmp/build.log 2>&1

(Apparently the version of texinfo in Homebrew isn't new enough for makeinfo and I didn't want to worry about that).

I've pasted my build log into this gist: https://gist.github.com/travisbhartwell/dd49d96fab0494919d7e1945ba4190b2

@rogermarlow
Contributor

I get the undefined cdr too. I got the texinfo package direct from the GNU site, but I don't think that's really the issue here.

@travisbhartwell

@rogermarlow Right, I mentioned texinfo to explain why I was using the --without-makeinfo parameter to configure. I didn't think it had anything to do with the error. Sorry for the confusion.

@ljos
Contributor
ljos commented Jan 18, 2017

(Apparently the version of texinfo in Homebrew isn't new enough for makeinfo and I didn't want to worry about that).

It is, but the package is keg only so you need to add /usr/local/opt/texinfo/bin to your PATH when building.

@ljos
Contributor
ljos commented Jan 18, 2017

It seems to me that the symbols make it into temacs but not into bootstrap-emacs. It is the temacs --batch --load loadup bootstrap command that outputs the rust_init_syms message. If you try to just run bootstrap-emacs it fails with emacs: Invalid function: cdr.

@rogermarlow
Contributor
rogermarlow commented Jan 18, 2017 edited

Not sure if this proves anything, but dumping the symbol tables from bootstrap-emacs and temacs gives the same output:

$ nm -a ./src/bootstrap-emacs > ~/tmp/bootstrap-emacs-symbols
$ nm -a ./src/temacs > ~/tmp/temacs-symbols
$ diff ~/tmp/bootstrap-emacs-symbols  ~/tmp/temacs-symbols
$

and grep'ing for cdr shows _Fcdr, _Qcdr and _Scdr.

@Wilfred Wilfred added a commit that referenced this issue Jan 18, 2017
@Wilfred Build on OS X too
Since this is increasing our build time, don't both testing on beta.

Related: #38
4da00c9
@crlf0710
Collaborator

Does this have something to do with the emacs unexec mechanism? I don't really understand the details though. Does
export CANNOT_DUMP=yes
before configure make things going?

@ljos
Contributor
ljos commented Jan 19, 2017

@rogermarlow is right. The symbols are there, but they are not found by the interpreter anymore. It could have something to do with unexec. I will test compiling with CANNOT_DUMP.

@ljos
Contributor
ljos commented Jan 19, 2017

It seems that emacs cannot build with CONNOT_DUMP=yes on macOS; I tried emacs HEAD@8c0fcaf and it fails on compiling too. This version does compile with CONNOT_DUMP=no though, so there is definitely something wrong with remacs.

@ljos
Contributor
ljos commented Jan 19, 2017

Removing bootstrap-emacs, running ln -f temacs bootstrap-emacs and calling make -C ../lisp compile-first EMACS=bootstrap-emacs and seeing it work for the first few files confirms for me that something is happening when emacs is dumping the temacs image. The rust pointers are not correctly read or restored.

@ljos
Contributor
ljos commented Jan 19, 2017 edited

Actually, it doesn't make sense that the printout in rust_init_syms should be printed on starting bootstrap-emacs. If we look at src/emacs.c#L1161 and know that rust_init_syms is called in syms_of_data, which is only called at src/emacs.c#L1191, we know that we shouldn't see that message on startup. What should happen is that after dumping emacs and undumping the symbols should be there; which is not the case.

@ljos
Contributor
ljos commented Jan 19, 2017 edited

Could this possibly be a hint?

The macOS implementation of unexec makes use of Darwin's `zone'
 memory allocator.  All calls to malloc, realloc, and free in Emacs
 are redirected to unexec_malloc, unexec_realloc, and unexec_free in
 this file.

Found at src/unexmacosx.c#L36.

@rogermarlow
Contributor

Let's be careful here. The error is Invalid function. Does that necessarily mean missing symbol or symbol not initialised? How does PUT_ERROR (Qinvalid_function, error_tail, "Invalid function"); work anyway?

@Wilfred Wilfred changed the title from Invalid function: eq to OS X compile fails with 'Invalid function: eq' Jan 19, 2017
@Wilfred
Owner
Wilfred commented Jan 20, 2017

OK, I've borrowed a Mac and I can reproduce this. I've experimented with moving rust_init_syms earlier in initialisation but no improvement.

I'm not sure that the zone memory allocator is affecting us -- rust_init_syms is largely dealing with static data.

@rogermarlow
Contributor

Reading the Emacs Lisp manual on how ELisp forms are evaluated:

If the first element of the list is a symbol then evaluation examines the symbol’s
function cell, and uses its contents instead of the original symbol.  If the contents
are another symbol, this process, called "symbol function indirection", is 
repeated until it obtains a non-symbol. [...] we eventually obtain a non-symbol, 
which ought to be a function or other suitable object.

More precisely, we should now have a Lisp function (a lambda expression), a
byte-code function, a primitive function, a Lisp macro, a special form, or an
autoload object.  [...]. 

If the object is not one of these types, Emacs signals an ‘invalid-function’ error.

So it would seem that on MacOS, the Rust code that populates the function cell for
the cdr symbol doesn't create something of a type that Emacs considers to be
appropriate for a function, i.e. a lambda, macro, primitive, etc.

@Wilfred Wilfred added a commit that referenced this issue Jan 21, 2017
@Wilfred Build on OS X too
Related: #38
2d13e11
@rogermarlow rogermarlow changed the title from OS X compile fails with 'Invalid function: eq' to OS X compile fails with 'Invalid function: cdr' Jan 22, 2017
@pnkfelix
Contributor
pnkfelix commented Jan 23, 2017 edited

@ljos wrote:

Could this possibly be a hint?

The macOS implementation of unexec makes use of Darwin's `zone'
memory allocator. All calls to malloc, realloc, and free in Emacs
are redirected to unexec_malloc, unexec_realloc, and unexec_free in
this file.

Found at src/unexmacosx.c#L36.

I did an experiment to test this theory: by using the #![allocator] feature, one can swap in a different crate that supplies the implementation for all of the malloc/realloc/free functionality that all of your crates (including the std lib) use.

So I made an allocator crate that mapped the three allocation functions to the unexec_ prefixed variants (that are built into the binary viaunexmacosx.c).

As far as I can tell this seems to resolve the problem with random invalid functions on Mac OS X in the bootstrap-emacs (!)


My current code is a complete hack that would break the other non OS X builds, but it at least provides evidence as to why we are seeing this problem on OS X but not on GNU hosts that support unexec natively.

  • Here is a commit that (I believe) captures my current hack. I am not 100% certain, because I was directly hacking the Makefiles at one point to work around cargo bugs, and then I shifted those changes into the Makefile.ins, but I have not tested redoing a full configure + build.
    • Update: yeah, my manual hacks to the makefiles worked around rust-lang/cargo#3586 in a manner that my changes to Makefile.in did not preserve.
    • So the linked commit will not build out of the box, due to rust-lang/cargo#3586 ; I am going to try to make another variant of the hack that does not use the [workspace] feature.
  • (The Makefile hacks were just an indirect consequence of my adding the #![allocator] crate locally to the project. They are not directly relevant to the problem at hand; e.g. if necessary we can put the #![allocator] crate into a first class entity on crates.io, if necessary.)
  • The important takeaway is that the allocator crate I added is trivial and represents effectively zero maintenance burden, apart from continuing to support the unexmacosx.c code itself. (See also #105 ; I would be happy to talk about switching to a portable dumper.)
@pnkfelix pnkfelix added a commit to pnkfelix/remacs that referenced this issue Jan 23, 2017
@pnkfelix pnkfelix override global allocator for Issue #38, eschewing cargo workspace fe…
…ature.
e3dd92e
@pnkfelix
Contributor

Here is a newer commit that avoids having to hack the Makefiles by not using cargo workspaces (and thus sidestepping rust-lang/cargo#3586).

It appears to run successfully on my Mac.

@philippkeller

thanks to the patch I was able to make remacs:

wget https://github.com/pnkfelix/remacs/commit/e3dd92ea2c63b364a70a07345a608450b3d6b90e.patch
git apply e3dd92ea2c63b364a70a07345a608450b3d6b90e.patch
make clean
make

When starting remacs with RUST_BACKTRACE=1 src/remacs -q though, the emacs windows opens but all keyboard input does go to the console instead of the emacs windows.

@pnkfelix
Contributor

@philippkeller yeah I don't remember the right way to deal with that with terminal apps that open windows (I vaguely remember there being some incantation that would fix it), but the simplest way to get a built Emacs to run in gui mode (rather than resorting to remacs -nw) is to open the built Emacs.app:

% ls -dlF src/remacs
-rwxr-xr-x  3 fklock  staff  23088708 Jan 23 21:33 src/remacs*
% ls -dlF nextstep/Emacs.app
drwxr-xr-x  3 fklock  staff  102 Jan 23 21:33 nextstep/Emacs.app/
% open ./nextstep/Emacs.app/
@benjamreynolds

Ive been following this one as I work on a mac and REALLY dont want to go through the brain damage of installing linux and dual booting. Im looking forward to getting started with Rust and Remacs and helping out as much as I can on this project and Im happy to do anything that would help move this one along.

@ljos
Contributor
ljos commented Jan 24, 2017 edited

@pnkfelix I can confirm that your patch works on my machine as well. Great job!

I think we should switch to the portable dumper as well, but it is, imo, very good that before that happens the macOS users are also able to hack on the source as well.

It seems the portable dumper work has stalled; last I saw was that in late december Daniel Colascione found a bug in his implementation. He hasn't pushed any branch yet, so it seems if we are going that route we need to fix his implementation ourselves or implement something new.

@pnkfelix pnkfelix added a commit to pnkfelix/remacs that referenced this issue Jan 26, 2017
@pnkfelix pnkfelix override global allocator for Issue #38, eschewing cargo workspace fe…
…ature.
8591f5f
@pnkfelix pnkfelix added a commit to pnkfelix/remacs that referenced this issue Jan 26, 2017
@pnkfelix pnkfelix override global allocator for Issue #38, eschewing cargo workspace fe…
…ature.
d360280
@pnkfelix pnkfelix added a commit to pnkfelix/remacs that referenced this issue Jan 26, 2017
@pnkfelix pnkfelix override global allocator for Issue #38, eschewing cargo workspace fe…
…ature.
66e25ed
@Wilfred Wilfred closed this in #112 Jan 27, 2017
@Wilfred Wilfred added a commit that referenced this issue Jan 27, 2017
@Wilfred Build on OS X too
Related: #38
c6858cf
@dgellow
dgellow commented Jan 27, 2017

@Wilfred I've git pulled and I still get the error

make[1]: Circular bootstrap-emacs <- temacs dependency dropped.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
  ELC      uvs.elc
emacs: Invalid function: cdr
make[2]: *** [uvs.elc] Error 1
make[1]: *** [macuvs.h] Error 2
make: *** [src] Error 2
@pnkfelix
Contributor

@dgellow try an explicit cargo clean and try again; my PR didn't update the makefile deps sufficiently

@Wilfred Wilfred added a commit that referenced this issue Jan 27, 2017
@Wilfred Build on OS X too
Related: #38
d04c1ef
@dgellow
dgellow commented Jan 27, 2017

@pnkfelix yep, you were right!

@Wilfred Wilfred added a commit that referenced this issue Jan 27, 2017
@Wilfred Build on OS X too
Related: #38
50569d1
@moosingin3space moosingin3space added a commit to moosingin3space/remacs that referenced this issue Jan 30, 2017
@pnkfelix @moosingin3space pnkfelix + moosingin3space override global allocator for Issue #38, eschewing cargo workspace fe…
…ature.
0408507
@moosingin3space moosingin3space added a commit to moosingin3space/remacs that referenced this issue Jan 30, 2017
@Wilfred @moosingin3space + moosingin3space Build on OS X too
Related: #38
db7dccc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment