On May 5, 2020, at 14:02, macpo...@parvis.nl wrote:

> man -c src/volumes/crc32/crc32.c
> mp  -c src/crc32c/crc32c.c 

> obviously i have a problem understandig github.
> 
> for the manual make i did git clone --recursive 
> 
> git log: 
> commit fc00689c77928b229707851931719fac937bf34c (tag: 0.3.2)
> Author: Adam Knight <a...@hopelessgeek.com>
> Date:   Wed Apr 2 12:23:17 2014 -0500
> 
> https://github.com/ahknight/hfsinspect/releases
> 
> on Apr 3, 2014 0.3.2 fc00689
> tar.gz -> https://github.com/ahknight/hfsinspect/archive/0.3.2.tar.gz
> 
> for macports i tried both
> github.setup        ahknight hfsinspect 0.3.2
> github.setup        ahknight hfsinspect 
> fc00689c77928b229707851931719fac937bf34c
> 
> but the code is different.

It sounds like you're simply getting different versions of the code when you do 
it in MacPorts vs. when you do it manually.

When you used github.setup and told MacPorts to get the code from tag 0.3.2, 
that's what it did.

But when you did a git clone, you probably got the master of the repository, 
which has had many commits after 0.3.2. One of those commits, for example, 
reorganized the repository and moved src/crc32/crc32.c to 
src/volumes/crc32/crc32.c:

https://github.com/ahknight/hfsinspect/commit/48eab4441834042fa7be69a33200d256cdfff680

Evidently one of the other changes after 0.3.2 must have been to fix the 
assembly error you encountered in 0.3.2. I see that after 0.3.2 the crc32c code 
in which the error occurred was moved to a separate github project (which is 
why when using master you have to use the --recursive flag to also download 
that other project as a submodule), and in that project, here's the commit that 
fixed that error:

https://github.com/ahknight/crc32c/commit/3831f5bdcb7bc2df1e3fa1c538bcd5f04b658e04

The fix was to use the cpuid.h header from the compiler, if it exists. 
Otherwise, it still falls back on the old implementation. A comment was then 
also added saying that the old implementation only supported "x86" (i386) not 
"x64" (x86_64). My recollection from dealing with cpuid issues in another 
project was that 10.7 has a cpuid.h implementation that is missing some 
features but that 10.8 and later have all the features. 10.6 and earlier don't 
have cpuid.h. Don't remember whether using a newer clang compiler on those 
older systems would provide a suitable cpuid.h but I think it did not.

Usually we want stable versions of ports in MacPorts. There hasn't been a new 
stable version of hfsinspect released after 0.3.2. It's been 6 years since the 
last stable release. It wouldn't be unreasonable for you to ask the developer 
to make a new stable release so that all the fixes they made after 0.3.2 can 
finally be used by users. But after all that time the developer may have lost 
interest any may never do another release. Another option is for you use 0.3.2 
but backport any needed fixes, such as the cpuid assembly fix. Whether that is 
easy or hard might depend on exactly how much the project has changed after 
0.3.2. If it turns out to be too difficult or if there end up being many more 
fixes to backport, you could just have the port install some other commit of 
the repo after 0.3.2 that works, until the developers release the next version.

Reply via email to