-
Notifications
You must be signed in to change notification settings - Fork 784
-
Notifications
You must be signed in to change notification settings - Fork 784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sometimes mrblib.o is not merged into libmruby.a #136
Comments
I am using GNU Make 3.81 on Mac OS X 10.7.4. |
I am not sure but "comparison is always true" warning may prevent mrblib compilation. |
Thank you for removing the warning. |
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. |
Thank you very much for trying to reproduce this problem. |
I can reproduce it here too. Since the mrblib/Makefile changed (10 hour ago) it also doesn't build correctly anymore:
As iwado this is fixing it for me too:
|
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. |
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. I am sorry that I have no idea for this issue. |
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. 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. |
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:
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. |
OK, splitting libmruby_nolib.a and libmruby.a sounds like a good idea. |
When libmruby.a and mrblib.o have the same timestamp, it may skip that Make merges mrblib.o to libmruby.a.
https://gist.github.com/2700367
The text was updated successfully, but these errors were encountered: