hfsinspect: src/crc32c/crc32c.c:29:13: error: instruction requires: Not 64-bit mode

[macports at parvis.nl]

> On 2020-05-06, at 02:40, Ryan Schmidt <ryandesign at macports.org> wrote:
> On May 5, 2020, at 14:02, macports at 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 <adam at 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.

first of all, thank you for the time you invested here.

you are right: i was using the wrong commit. if for manual git clone i use fc0068 i get the same error as in my portfile.