1.6.34 build scripts.
xrpdevs opened this issue · comments
Build is failing and package ignores -tags builtin_shared and defaults to only ever using the prebuilt libs in ./dist
Why are binaries included in the SOURCE package?
The libs included are compiled for a system that has AVX2 support, meaning that when used on any system that doesn't have AVX2, we get "Illegal Instruction" errors.
Has the build system been corrected in any later versions?
From what I could see, either grocksdb or one of the dependencies that the build scripts download are unable to install files to system areas (there is an error that says "do you need administrative access" - at which point the build fails to include libzstd in the build target area)
if we're just building stuff to be included in a go package, we shouldn't be trying to install it into system directories.
@xrpdevs Could you please give me your steps/script of building? There is no builtin_shared tag like you said. And grocksdb basically encourage building with shared lib rather than builtin_static lib.
To use pre-built lib, you need to understand the abi compatibility with your local runtime.
Hi, and thanks for getting back to me on this.
I meant builtin_static rather than builtin_shared.
If you don't specify "-tags builtin_static" grocksdb still uses the pre-compiled builtin static libs.
This is why projects like AvalancheGo which have grocksdb as a dependency can't run on machines that don't support AVX2 instruction set if they use grocksdb as a database wrapper.
If you try to build the golang package from source, without specifying -tags builtin_static the build script ignores this and still tries to build the static libs.
Static libs build fails because the libzstd makefile tries to install things to system directories requiring root access, causing an error and preventing "libzstd.a" from being moved to ./dist/..../lib/
It's late here now but tomorrow I will post a dump of the output when trying to build.
To get libzstd.a built with -march=native I had to interrupt the build process before temp files are deleted, move it out of the build dir, then restart process.
Because this is failing, only way I could make this work using the static libs was to manually copy them into the ./dist folder of the go package cache /pkg/mod/github.com/linxGnu/
As far as I can tell there is no option to use system shared libs due to build defaulting to use builtin_static only
Hope this helps.
FWIW, including pre-compiled static libraries in a source package is probably not a very good idea from a security standpoint (especially when we're unable to use the system libraries due to build script only using the included libs) as there is no easy way to verify that the executables don't contain malicious code.
@xrpdevs yup I know and agree with your points about security. Thats the reason why I dont highlight this method in README. Prebuilt lib is my own purpose for my own business.
What I recommend is “shared_lib”. Not builtin static lib. And you touch my prebuilt static lib if and only if you enable tag “builtin_static”. By default, go compiler would invoke linker and try to find shared lib.
Therefore, its user decision to use it or not!
I think you are misunderstanding a lot.
And to build rocksdb shared lib, its not the duty of grocksdb. Please also kindly refer to rocksdb guideline. You could find it at rocksdb wiki, written by rocksdb author.
I know it's not the purpose of grocksdb to build RocksDB, but again, the point I am trying to make, is that if "-tags builtin_static" isn't specified, grocksdb still uses the builtin static.
@xrpdevs No, “without” the tag, your build would link to shared lib, NOT builtin static.
As I said, you only touch my builtin IF AND ONLY IF you specify the tag
Then why do I still get "Illegal Instruction" error when I omit -tags builtin_static ?
From https://docs.avax.network/build/references/command-line-interface
"Two important notes about RocksDB: First, RocksDB does not work on all computers. Second, RocksDB is not built by default and is not included in publicly released binaries."
There is no reason that RocksDB can't run on any 64 bit CPU.
From https://github.com/ava-labs/avalanchego/blob/master/scripts/build_avalanche.sh
echo "Building AvalancheGo with rocksdb enabled..." go build -tags rocksdballowed -ldflags "-X github.com/ava-labs/avalanchego/version.GitCommit=$git_commit $static_ld_flags" -o "$avalanchego_path" "$AVALANCHE_PATH/main/"*.go
As you can see, -tags builtin_static isn't specified, yet when go pulls and builds the dependencies, the resulting grocksdb package is still using the builtin static libraries, resulting in Illegal Instruction errors.
@xrpdevs I wonder why you conclude illegal instruction come from my prebuilt static lib. Did you try to remove “dist” folder to see what happen?
if linker links to my lib, you will see file not found err. If you still have illegal instruction, then please check your shared lib.
Fyi @xrpdevs someone tried grocksdb on arm isa without problem
Will check this tomorrow, it's 4:43AM here and I need sleep.
I know illegal instruction comes from the prebuilt lib because I used GDB to run a trace, when switching to assembly layout I see its halted on an AVX2 instruction which my CPU doesn't support.
@xrpdevs Hello, I wonder if your problem gone? If have, please don't hesitate to tell me. Thank.
Did you make any changes in your build setup? I don't use grocksdb as a dependency in any projects of my own, but it is a dependency of something I use. I'll download your latest and take a look, if build works then I will let the AvalancheGo and Flare networks people know to update their dependencies.
If it still has problems then I'll pull your upstream changes and try to fix then submit a PR for you to look at. Have been busy with other things this week.
@xrpdevs oh, I have just adapted (nearly latest) rocksdb (6.25.3). Also remove builtin static lib after migrating at my own business. I think it's worth to take a look and may fix your problem.
Cool, did you see the issue with the libzstd.a file not being moved to the target dir in ./dist... ? That was why it was failing, perhaps the make arguments needed to be changed. I'll take a look in the morning.
@xrpdevs yep, I know about it. But never think it affects shared_lib building because linker is the one responsible in this case.
Anyway, my latest release also fix build.sh script. Hope this fix your problems
I will close this issue. Please reopen it if you still have problem. Thank you @xrpdevs