Code Monkey home page Code Monkey logo

Comments (11)

iwadon avatar iwadon commented on September 13, 2024

I am using GNU Make 3.81 on Mac OS X 10.7.4.

from mruby.

matz avatar matz commented on September 13, 2024

I am not sure but "comparison is always true" warning may prevent mrblib compilation.
I removed the warning in a3a9d13, please see if it works.

from mruby.

iwadon avatar iwadon commented on September 13, 2024

Thank you for removing the warning.
I updated the log: https://gist.github.com/2700367

from mruby.

matz avatar matz commented on September 13, 2024

I cannot reproduce the problem on the Linux box. I have no idea why make ignores creating mrblib.o and archiving it on your platform. Hmm.

from mruby.

iwadon avatar iwadon commented on September 13, 2024

Thank you very much for trying to reproduce this problem.
As the makeshift patch, I added .PHONY: $(LIBR) to mrblib/Makefile.
It works fine for me. But it always remakes libmruby.a.

from mruby.

bovi avatar bovi commented on September 13, 2024

I can reproduce it here too. Since the mrblib/Makefile changed (10 hour ago) it also doesn't build correctly anymore:

gcc -o ../../bin/mruby -g -O3 ../../src/../tools/mruby/mruby.o ../../lib/libmruby.a  -lm
Undefined symbols for architecture x86_64:
  "_mrb_init_mrblib", referenced from:
      _mrb_init_core in libmruby.a(init.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[1]: *** [../../bin/mruby] Error 1
make: *** [all] Error 2

As iwado this is fixing it for me too:

diff --git a/mrblib/Makefile b/mrblib/Makefile
index 7129623..12ee23d 100644
--- a/mrblib/Makefile
+++ b/mrblib/Makefile
@@ -45,6 +45,8 @@ endif
 .PHONY : all
 all : $(LIBR)

+.PHONY : $(LIBR)
+
 # update libmruby.a
 $(LIBR) : $(MLIB)
        $(AR) r $(LIBR) $(MLIB)

from mruby.

matz avatar matz commented on September 13, 2024

I don't want phony that forces libmruby.a to be updated.

What I don't understand is the reason why "make mrblib" don't update libmruby.a.
Top-level make run "make src" then "make mrblib", so the timestamp of mrblib.o should be newer than libmruby.a. Is anyone able to guess the situation?

from mruby.

iwadon avatar iwadon commented on September 13, 2024

GNU make on Mac OS X uses low resolution timestamp, maybe.

http://www.doof.me.uk/2012/04/21/portable-high-resolution-timestamps-from-stat/

Mac OS X can use stat.st_mtimespec not stat.st_mtim.
But GNU make checks stat.st_mtim only for high resolution timestamp checking.
(see "whether to use high resolution file timestamps" in configure.in)

I am sorry that I have no idea for this issue.

from mruby.

iwadon avatar iwadon commented on September 13, 2024

This is the problem depending on the file system. GNU make is not guilty.

The date resolution of HFS+ and other more filesystems is 1 second.
http://en.wikipedia.org/wiki/HFS_Plus
http://en.wikipedia.org/wiki/Ext3

If the difference of the time when libmruby.a and mrblib.o are made becomes less than 1 second and the timestamps of both files are same, this problem will occur.

from mruby.

mitchblank avatar mitchblank commented on September 13, 2024

Yeah, I've just hit this too.. I'm building on a fast OS/X machine with an SSD and I hit it almost every build. I've been doing:

$ make -j12 ; touch mrblib/mrblib.o ; make -j12

to get around it for now.

I think having multiple make rules updating "libmruby.a" is just never going to work 100% safely.. just too complicated since its effectively a circular dependency (libmruby.a -> mrbc -> libmruby.a) which is hard to get make to deal with correctly.

I think the best solution would be to just split this into two libraries (libmruby_nolib, libmruby) Doing the "ar" is fast, so doing that part twice won't affect the compile speed. This also will be needed when crosscompiling support is added (important for the embedded space!) since then you'll have to build the engine twice: once for the host processor to build the lib, and a second time for the target processor. Might as well start getting the distinction in place.

from mruby.

matz avatar matz commented on September 13, 2024

OK, splitting libmruby_nolib.a and libmruby.a sounds like a good idea.

from mruby.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.