Skip to content
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.

Sign up for GitHub

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

Jump to bottom

nimble install rocksdb fails with build issue #73

Open
arnetheduck opened this issue Dec 9, 2024 · 11 comments
Open

nimble install rocksdb fails with build issue #73

arnetheduck opened this issue Dec 9, 2024 · 11 comments
Assignees
@bhartnett

Comments

@arnetheduck
Copy link
Member 

arnetheduck@praeceps:~/tmp$ mkdir test
arnetheduck@praeceps:~/tmp$ cd test
arnetheduck@praeceps:~/tmp/test$ nimble install -l rocksdb
   Warning: Using project local deps mode
Downloading Official package list
    Success Package list downloaded.
      Info: using /home/arnetheduck/.nimble/nimbinaries/nim-2.2.0/bin/nim for compilation
 Installing nim@2.2.0
  Success:  nim installed successfully.
      Info: using /home/arnetheduck/tmp/test/nimbledeps/pkgs2/nim-2.2.0-a991d792809b797a5b0de01eb7165fdfd1077509/bin/nim for compilation
[NimScript] exec: scripts/build_shared_deps_linux.sh
Downloading vcpkg-glibc...
vcpkg package management program version 2024-09-30-ab8988503c7cffabfd440b243a383c0a352a023d

See LICENSE.txt for license information.
Computing installation plan...
The following packages will be built and installed:
  * lz4:x64-linux-rocksdb@1.10.0
    rocksdb[core,lz4,zlib,zstd]:x64-linux-rocksdb@9.6.1
  * zlib:x64-linux-rocksdb@1.3.1
  * zstd:x64-linux-rocksdb@1.5.6
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-linux-rocksdb...
Compiler found: /usr/bin/c++
Restored 0 package(s) from /home/arnetheduck/.cache/vcpkg/archives in 6.42 us. Use --debug to see more details.
Installing 1/4 lz4:x64-linux-rocksdb@1.10.0...
Building lz4:x64-linux-rocksdb@1.10.0...
/home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/triplets/x64-linux-rocksdb.cmake: info: loaded overlay triplet from here
-- Using cached lz4-lz4-v1.10.0.tar.gz.
-- Cleaning sources at /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/src/v1.10.0-61bd08d80e.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/downloads/lz4-lz4-v1.10.0.tar.gz
-- Applying patch target-lz4-lz4.diff
-- Using source at /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/src/v1.10.0-61bd08d80e.clean
-- Found external ninja('1.12.1').
-- Configuring x64-linux-rocksdb
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:127 (message):
    Command failed: /usr/bin/ninja -v
    Working Directory: /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/x64-linux-rocksdb-rel/vcpkg-parallel-configure
    Error code: 1
    See logs for more information:
      /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/config-x64-linux-rocksdb-rel-CMakeCache.txt.log
      /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/config-x64-linux-rocksdb-rel-CMakeConfigureLog.yaml.log
      /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/config-x64-linux-rocksdb-out.log

Call Stack (most recent call first):
  installed/x64-linux/share/vcpkg-cmake/vcpkg_cmake_configure.cmake:269 (vcpkg_execute_required_process)
  ports/lz4/portfile.cmake:16 (vcpkg_cmake_configure)
  scripts/ports.cmake:192 (include)


error: building lz4:x64-linux-rocksdb failed with: BUILD_FAILED
See https://learn.microsoft.com/vcpkg/troubleshoot/build-failures?WT.mc_id=vcpkg_inproduct_cli for more information.
Elapsed time to handle lz4:x64-linux-rocksdb: 166 ms
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
  https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+lz4
You can submit a new issue at:
  https://github.com/microsoft/vcpkg/issues/new?title=[lz4]+Build+error+on+x64-linux-rocksdb&body=Copy+issue+body+from+%2Fhome%2Farnetheduck%2F.nimble%2Fpkgcache%2Fgithubcom_statusimnimrocksdb%2Fvendor%2Fvcpkg%2Finstalled%2Fvcpkg%2Fissue_body.md

stack trace: (most recent call last)
/tmp/nimblecache-3350794988/nimscriptapi_811832782.nim(228, 29)
/home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/rocksdb.nimble(43, 5) installBefore
/home/arnetheduck/tmp/test/nimbledeps/pkgs2/nim-2.2.0-a991d792809b797a5b0de01eb7165fdfd1077509/lib/system/nimscript.nim(264, 7) exec
/home/arnetheduck/tmp/test/nimbledeps/pkgs2/nim-2.2.0-a991d792809b797a5b0de01eb7165fdfd1077509/lib/system/nimscript.nim(264, 7) Error: unhandled exception: FAILED: scripts/build_shared_deps_linux.sh [OSError]
       Tip: 5165 messages have been suppressed, use --verbose to show them.
nimscriptwrapper.nim(166) execScript

    Error:  Exception raised during nimble script execution
arnetheduck@praeceps:~/tmp/test$
@bhartnett
Copy link
Contributor

I'm not able to reproduce this failure. I'm using linux with Nim version 2.2.0 and the build completes with no issues when I run nimble install -l rocksdb from an empty directory and it also works fine when I run nimble install from inside the project directory.

@bhartnett
Copy link
Contributor

@arnetheduck It appears that nimble install is working. I've tested locally on two linux devices and also in the CI and all builds complete with no issues, see here: #74

@arnetheduck
Copy link
Member Author

Hm, it looks like it's using vcpkg for that and I get the above error when that happens - more interestingly though, it's also not using the version from our vendor submodule as far as I can tell from that pr:

    rocksdb[core,lz4,zlib,zstd]:x64-linux-rocksdb@9.6.1

we're at a newer version.

I also checked what's actually going wrong:

    Run Build Command(s): /usr/bin/ninja -v cmTC_94d56
    [1/2] /usr/bin/cc   -fPIC -o CMakeFiles/cmTC_94d56.dir/testCCompiler.c.o -c /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/x64-linux-rocksdb-rel/CMakeFiles/CMakeScratch/TryCompile-DCEDPk/testCCompiler.c
    [2/2] : && /usr/bin/cc -fPIC -static CMakeFiles/cmTC_94d56.dir/testCCompiler.c.o -o cmTC_94d56   && :
    FAILED: cmTC_94d56 
    : && /usr/bin/cc -fPIC -static CMakeFiles/cmTC_94d56.dir/testCCompiler.c.o -o cmTC_94d56   && :
    /usr/bin/ld: error: cannot find -lc
    /usr/lib/gcc/x86_64-redhat-linux/14/../../../../lib64/crt1.o:function _start:(.text+0x21): error: undefined reference to '__libc_start_main'
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.

It's performing a test to see if I have the static version of libc/libstd++ installed - this is often not the case and broadly I think the shared versions of said libraries should be used even if we create a static rocksdb, so this looks like a bug.

@arnetheduck
Copy link
Member Author 

arnetheduck@praeceps:~/.nimble/pkgs2/rocksdb-0.5.0-48066776c00c7afcdafd721696be89fd41f91670$ find
.
./rocksdb.nim
./rocksdb
./rocksdb/backup.nim
./rocksdb/columnfamily.nim
./rocksdb/columnfamily
./rocksdb/columnfamily/cfdescriptor.nim
./rocksdb/columnfamily/cfhandle.nim
./rocksdb/columnfamily/cfopts.nim
./rocksdb/internal
./rocksdb/internal/cftable.nim
./rocksdb/internal/utils.nim
./rocksdb/lib
./rocksdb/lib/librocksdb.nim
./rocksdb/lib/rocksdb.h
./rocksdb/lib/rocksdb_gen.nim
./rocksdb/optimistictxdb.nim
./rocksdb/options
./rocksdb/options/backupopts.nim
./rocksdb/options/cache.nim
./rocksdb/options/dbopts.nim
./rocksdb/options/readopts.nim
./rocksdb/options/tableopts.nim
./rocksdb/options/writeopts.nim
./rocksdb/rocksdb.nim
./rocksdb/rocksiterator.nim
./rocksdb/rocksresult.nim
./rocksdb/snapshot.nim
./rocksdb/sstfilewriter.nim
./rocksdb/transactiondb.nim
./rocksdb/transactions
./rocksdb/transactions/otxopts.nim
./rocksdb/transactions/transaction.nim
./rocksdb/transactions/txdbopts.nim
./rocksdb/transactions/txopts.nim
./rocksdb/writebatch.nim
./rocksdb/writebatchwi.nim
./rocksdb.nimble
./nimblemeta.json

there's also no actual installed rocksdb library here that applications can link to

@bhartnett
Copy link
Contributor

Hm, it looks like it's using vcpkg for that and I get the above error when that happens - more interestingly though, it's also not using the version from our vendor submodule as far as I can tell from that pr:

    rocksdb[core,lz4,zlib,zstd]:x64-linux-rocksdb@9.6.1

Yes we use vcpkg for building the rocksdb dynamic libraries on all platforms. This is the only viable way that I'm aware of. For the static libraries on linux and mac we use the rocksdb make file.

we're at a newer version.

Actually I just updated the version today to 9.7.2 but before my update today 9.6.1 was the correct version.

I also checked what's actually going wrong:

    Run Build Command(s): /usr/bin/ninja -v cmTC_94d56
    [1/2] /usr/bin/cc   -fPIC -o CMakeFiles/cmTC_94d56.dir/testCCompiler.c.o -c /home/arnetheduck/.nimble/pkgcache/githubcom_statusimnimrocksdb/vendor/vcpkg/buildtrees/lz4/x64-linux-rocksdb-rel/CMakeFiles/CMakeScratch/TryCompile-DCEDPk/testCCompiler.c
    [2/2] : && /usr/bin/cc -fPIC -static CMakeFiles/cmTC_94d56.dir/testCCompiler.c.o -o cmTC_94d56   && :
    FAILED: cmTC_94d56 
    : && /usr/bin/cc -fPIC -static CMakeFiles/cmTC_94d56.dir/testCCompiler.c.o -o cmTC_94d56   && :
    /usr/bin/ld: error: cannot find -lc
    /usr/lib/gcc/x86_64-redhat-linux/14/../../../../lib64/crt1.o:function _start:(.text+0x21): error: undefined reference to '__libc_start_main'
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.

I wonder if there is a bug when building on a different linux distro. What distro are you using by the way?

It's performing a test to see if I have the static version of libc/libstd++ installed - this is often not the case and broadly I think the shared versions of said libraries should be used even if we create a static rocksdb, so this looks like a bug.

We don't control or configure this anywhere in nim-rocksdb. If there is a bug it might be in the upstream vcpkg configuration but to confirm I'd like to be able to reproduce it first somehow.

@bhartnett
Copy link
Contributor 

arnetheduck@praeceps:~/.nimble/pkgs2/rocksdb-0.5.0-48066776c00c7afcdafd721696be89fd41f91670$ find
.
./rocksdb.nim
./rocksdb
./rocksdb/backup.nim
./rocksdb/columnfamily.nim
./rocksdb/columnfamily
./rocksdb/columnfamily/cfdescriptor.nim
./rocksdb/columnfamily/cfhandle.nim
./rocksdb/columnfamily/cfopts.nim
./rocksdb/internal
./rocksdb/internal/cftable.nim
./rocksdb/internal/utils.nim
./rocksdb/lib
./rocksdb/lib/librocksdb.nim
./rocksdb/lib/rocksdb.h
./rocksdb/lib/rocksdb_gen.nim
./rocksdb/optimistictxdb.nim
./rocksdb/options
./rocksdb/options/backupopts.nim
./rocksdb/options/cache.nim
./rocksdb/options/dbopts.nim
./rocksdb/options/readopts.nim
./rocksdb/options/tableopts.nim
./rocksdb/options/writeopts.nim
./rocksdb/rocksdb.nim
./rocksdb/rocksiterator.nim
./rocksdb/rocksresult.nim
./rocksdb/snapshot.nim
./rocksdb/sstfilewriter.nim
./rocksdb/transactiondb.nim
./rocksdb/transactions
./rocksdb/transactions/otxopts.nim
./rocksdb/transactions/transaction.nim
./rocksdb/transactions/txdbopts.nim
./rocksdb/transactions/txopts.nim
./rocksdb/writebatch.nim
./rocksdb/writebatchwi.nim
./rocksdb.nimble
./nimblemeta.json

there's also no actual installed rocksdb library here that applications can link to

Hmm, that is odd. There is meant to be a build directory here which the shared library gets copied into. I'll look into this further.

@arnetheduck
Copy link
Member Author

I wonder if there is a bug when building on a different linux distro. What distro are you using by the way?

fedora - on there, the glibc-static and libstd++-static packages need to be installed separately. this is always a mess, ie "build a static version of my library that depends on a dynamic libc" or "everything static" or anything in between.

@bhartnett
Copy link
Contributor

I wonder if there is a bug when building on a different linux distro. What distro are you using by the way?

fedora - on there, the glibc-static and libstd++-static packages need to be installed separately. this is always a mess, ie "build a static version of my library that depends on a dynamic libc" or "everything static" or anything in between.

Ok, I've reproduced the issue on Fedora and I've confirmed that it breaks due to those missing libraries as you suggested.

To fix the issue I can update the vcpkg configuration to make rocksdb link to the dependencies dynamically. The downside is that those libraries may need to be packaged/included with the rocksdb library when it gets used.

@bhartnett
Copy link
Contributor

The fix is included in this PR: https://github.com/status-im/nim-rocksdb/pull/76/files

@arnetheduck
Copy link
Member Author

To fix the issue I can update the vcpkg configuration to make rocksdb link to the dependencies dynamically. The downside is that those libraries may need to be packaged/included with the rocksdb library when it gets used.

I think what we're aiming for is that glibc/libstdc++ is shared but the deps (zstd etc) are static - it's the "default" when creating static libraries that a shared c library is still used. The odd thing in this build failure was that it was trying to use a static c library as well.

@bhartnett
Copy link
Contributor

bhartnett commented Dec 16, 2024 •
edited
Loading

I think what we're aiming for is that glibc/libstdc++ is shared but the deps (zstd etc) are static - it's the "default" when creating static libraries that a shared c library is still used. The odd thing in this build failure was that it was trying to use a static c library as well.

Sure, I agree this sounds like a better approach.

Setting VCPKG_CRT_LINKAGE to 'dynamic' appears to fix the issue on Fedora while still building the static libraries. See changes here: #78

@bhartnett bhartnett self-assigned this Dec 17, 2024
@bhartnett bhartnett mentioned this issue Dec 17, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bhartnett bhartnett

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@arnetheduck @bhartnett