-
Notifications
You must be signed in to change notification settings - Fork 240
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
version 1.49 unbuildable on linux #470
Comments
Just found out the same issue. Wondering the same as @wdoekes Thanks |
g++ -DHAVE_CONFIG_H -I. -Wall -Werror -std=c++11 -I./linux -I./Common -I./Common/pbkdf2 -I./linux -I./LinuxPBA -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -c -o LinuxPBA/UnlockSEDs.o LinuxPBA/UnlockSEDs.cpp |
Hey @scottcmarks would you manage to look into your problematic commit? |
Can authors please explain meaning of new versioning scheme? So far, no Linux distribution builds Also, can you please explain meaning of Curiously, both |
@r0m30, apologies for pinging you, but do you still have access to this repo? Since the author of the problematic commit went AWOL, there is a need to fix this somehow. |
@youk I don't know if I still have access to the repo. I haven't checked since the first of the year. |
This was on a feature branch, so ymmv. Those tags are now on the develop branch, still entirely tentative.
with optional
has been percolating for me quite reliably. Linux, libc etc versions on request as I update them and rebuild several times a day. The idea of a 1.49 version is that it is just under a 1.5 version, which in turn is halfway to a 2.0 version, which is what I am heading toward. The idea, which seems to be panning out, is that by creating an explicit DtaDrive layer adhering to the standards for Ata (HD), Sata (SAT passthrough), Scsi ("direct" Scsi or SAS), and NVMe there is almost no need for separate linux, etc. (OS-specific) subfolders full of duplicative code. (Although it might be time to retire HD Ata code, the non-SCSI-intermediated NVMe code presents essentially the same problems, so two birds with one stone.). Instead, each will contain the implementation of a singleton of its subclass of DtaOS (e.g. DtaLinux) with its OS-specific implementation of eight or so methods, e.g. PerformSCSICommand, which itself takes standard-set (OS-independent) parameters. The 1.5 version is just that; in the 2.0 architecture, the interface to DtaDrive and its kin will be simplified to identify, IF_SEND, and IF_RECV, and the "command-writing" code of the many utility functions will be trimmed down by using the new closure-based wrappers for the common cases. |
Authors mis-invented concept of branches using tags. sedutil: 1f13670b010dceec38bc95d7a7d223a8709864e6 refs/tags/linux_works origin sedutil: 1f13670b010dceec38bc95d7a7d223a8709864e6 refs/tags/windows_works origin sedutil: 9106b4994ea1cf992f374e91af2e5a8d9bf5b466 refs/tags/macos_works origin Link: Drive-Trust-Alliance/sedutil#470 (comment) Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
Many issues with 1.49. Was this release intentional?
#define LOGX
is done twiceOPAL_DiskInfo
is nowDTA_DEVICE_INFO
void DtaDevOS::identify
should bebool ...
The text was updated successfully, but these errors were encountered: