-
Notifications
You must be signed in to change notification settings - Fork 4
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
Nanosecond precision timestamps support broken on macOS / BSD / AIX / Solaris #4542
Comments
|
Apparently, macOS fixed itself: Homebrew/homebrew-core#173306
Need to check what's up in the BSD land. |
stat -f %Fm filename can be used if ls is unable to show nanosecond timestamps. |
MacPorts PR: macports/macports-ports#24224 |
Branch: 4542_nanoseconds_cleanup
Hi Andrew, appreciate reviewing this stuff, maybe you can check on Linux? I've checked it on macOS and it works, will be trying on AIX shortly, it's a bit of a pain to build. I hope my idea is clear. If not just ask. Please feel free to commit fixups directly if you don't like something. I tried my best to keep to your style. |
Let's move cleanup stuff to new branch 4524_cleanup or commit it directly to master.
Move #include <config.h> to .h is not a good idea. config.h must be included first in .c files, but indirectly includes via other headers became it not first.
but defined here:
|
Sorry, I don't get what you want. I think it's better to have a separate branch for nanoseconds stuff instead of doing everything in cleanup. It's a new feature supporting it correctly on AIX & BSDs. The commits doing the refactoring make it possible to implement the new feature centrally, so I would also keep them to this branch.
If you want to take [607fe8] and [c50106] elsewhere, no problem, but I would prefer master, so that I can rebase this branch and continue testing. Regarding [c50106], I'm not sure if something else has to be changed / removed. The function was present before glib 2.31 according to git blame of their tree, so maybe something went wrong at some point?
Ah, ok, thank you, I put it back. I thought it was unused, but I was wrong.
But am I allowed also to use config.h in h-files? Are there any rules for that? I need to know the structure of the struct and I want the functions to be in h-files, so that they can be inlined everywhere, where they are used. |
Replying to zaytsev:
Ok.
That's my mistake. There was no need to redefine g_direct_equal() in our code because it's implemented in glib since 2005.
I've never seen <config.h> included in h-files, only in c-files.
Probably yes, but Google can't help me.
Your h-files are included in c-files after config.h so no problems. |
Okay, I understand, so the rule is to use config.h in C-files so that it doesn't contaminate other files per mistake if used in an H-file, and use it first. I can check if there are other H-files where we include it by mistake.
These are nothing but accessor functions that reshuffle struct fields. Before my changes it was handled at every place where it was needed in the code. Now everywhere there is an extra function call, but the code is reused. I wanted to make it a function and not a macro, because macros are evil and non-type-safe. But it has some performance impact. For inline functions the impact is zero.
But if we don't care, then I can move these functions in a C-file, probably the impact will be some microseconds anyways which are not important... |
I have added a commit implementing this, took the two build fixes in master and rebased the branch squashing the fixups. |
I've created an alternative branch with some fixups: 4542_nanoseconds_2 |
|
I'm a bit concerned about you removing config.h from vfs.h - it means vfs.h must be only included in C-files which include config.h themselves to work correctly. But I guess this is C life :-(
Thank you for the rest of the changes, I think I tried %ju but got some problems on Mac and AIX, and decided to use %llu. I will test again on Mac, AIX and I also wanted to check Solaris. Then report back. |
Replying to zaytsev:
Yes. We do compile c-files, not h-files. c-file must begin with include of config.h, then include system-wide h-files (from /usr/include), then project h-files.
I get a warning for %llu:
and system_data_types(7) says:
|
Been busy with other stuff, but probably should just test on Solaris and be done with it. Will see how I can get back to it. |
Started building on Solaris, still struggling to compile the dependencies. Libffi is done:
Glib needs more work.
Glib is done with lots of makefile editing to remove -Wl,... and disable linking binaries / tests. Maybe newer versions than glib-2.43.92.tar.xz are not as bad, but at some point they started depending on a non-autotools build system... even more pain.
Slang was "easy":
mc was also okay, but patches are needed (see below):
|
May I commit the following two patches directly to master?
|
N.B. Tested nanosecond timestamps on Solaris, they work now. Solaris supports ls -alsE to show them. |
|
I've retested on AIX 7.3 and it looks really good. The timestamps are also preserved.
I've looked at your changes, Andrew, and I agree with all of them, thank you for your help! Without you I've probably wouldn't come that far. How do we go about merging this branch? Shall I take yours, rebase and merge? Or you want to do this? |
Rebased - changeset: [bfa0f041cf84ec169c3a72538bddf461dd8bd256] . |
|
|
Replying to zaytsev:
Yes, please.
Replying to zaytsev:
Why not to the current branch before merge? |
No problem, can do that :) Last time you didn't want "unrelated" patches fixing the build system in the topic branches, which is why I asked. |
|
|
Important
This issue was migrated from Trac:
zaytsev
(@zyv)ag
(andrey.gursky@…-mail.ua)Followup ticket to:
Sadly no-one came around to fix this, so packagers still disable the support manually:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/m/midnight-commander.rb
https://github.com/macports/macports-ports/blame/master/sysutils/mc/Portfile
Here are the notes how to possible fix this:
---
Unfortunately, I think that the easiest way to access XNU sources from macOS 10.13 right now would be to get hired as a kernel developer by Apple. The system is not even officially released to the public yet (target date is 25th of September), and sources are usually released some time after the final release.
Anyways, I believe that source code access is not really necessary in the first place, as I would speculate that all one needs to do is to add
and wherever we use HAVE_STRUCT_STAT_ST_MTIM *or* HAVE_UTIMENSAT replace it with
or something along these lines and you will magically not only fix the build, but gain nanosecond precision support for macOS 10.13+ *and* BSD at the same time. Of course, cruft keeps accumulating, so ideally one should think about defining clever struct manipulation functions limiting define proliferation...
Better yet would be to undertake a major refactoring to clean up our time mess afterwards, but that's, of course, just wishful thinking.
Note
Original attachments:
zaytsev
(@zyv) onJul 27, 2024 at 20:07 UTC
The text was updated successfully, but these errors were encountered: