vg
vg copied to clipboard
vgteam
glibtool: link: Waiting for libspinlock.a.lock to be removed
When compiling vg from source on macOS, I encountered this unusual libtool error message, which I haven't encountered before.
glibtool: link: ( cd ".libs" && rm -f "liblogging.la" && ln -s "../liblogging.la" "liblogging.la" )
glibtool --tag=CXX --mode=link /Users/sjackman/.homebrew/Homebrew/Library/Homebrew/shims/super/g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -Wno-unused-result -fsized-deallocation -DNO_FRAME_POINTER -g -O2 -export-symbols-regex '(GetStackTrace|GetStackFrames|GetStackTraceWithContext|GetStackFramesWithContext)' -no-undefined -o libstacktrace.la src/stacktrace.lo src/base/elf_mem_image.lo src/base/vdso_support.lo libspinlock.la libsysinfo.la liblogging.la
glibtool: link: Waiting for /private/tmp/vg-20180301-88698-qvexea/deps/gperftools/./.libs/libspinlock.a.lock to be removed
glibtool: link: Waiting for /private/tmp/vg-20180301-88698-qvexea/deps/gperftools/./.libs/libspinlock.a.lock to be removed
…
Here's the complete build log: https://gist.github.com/sjackman/a926314a4e1311a28f00be95f52b4d49#file-01-make-L2406
Here's the work-in-progress Homebrew formula: https://github.com/brewsci/homebrew-bio/pull/179
What happens when you remove the file manually from another terminal?
We are already using brew in the Travis CI tests, so maybe this will give you some hints for the homebrew formula: https://github.com/vgteam/vg/blob/master/.travis.yml#L35-L48
I'd love to help more but unfortunately I don't have access to OSX except through Travis. Thank you for working on a brew formula! Let's get this working. FWIW I'm going to cut a new release this week (1.7.0), but it should be easy to update once you've got it working.
This error is reproducible on my machine at work, but if I don't see it at home or on CircleCI, I wouldn't worry about it.
No worries at all! I'm keen to try the assembly overlap trimming function of vg.
I'm able to reproduce this issue at home as well.
What happens when you remove the file manually from another terminal?
The file does not exist.
glibtool: link: Waiting for /private/tmp/vg-20180329-92568-16gp7xj/deps/gperftools/./.libs/libspinlock.a.lock to be removed
❯❯❯ ls /private/tmp/vg-20180329-92568-16gp7xj/deps/gperftools/./.libs/libspinlock.a.lock
ls: /private/tmp/vg-20180329-92568-16gp7xj/deps/gperftools/./.libs/libspinlock.a.lock: No such file or directory
Could vg use the brewed version of gperftools rather than compile it from scratch?
Yes, that'd be a possibility. I guess the makefile would have to be adjusted to understand this. I'm perplexed that we can build on travis with this problem.
On Sat, Mar 31, 2018 at 9:40 AM Shaun Jackman [email protected] wrote:
Could vg use the brewed version of gperftools rather than compile it from scratch?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/vgteam/vg/issues/1586#issuecomment-377673975, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI4EQGp7YllTiDnYMEImCDBJGmyO5Jhks5tjzLmgaJpZM4TBMwj .
I believe TravisCI uses Ubuntu 14.04 LTS (Trusty Tahr) by default, whose default compiler is GCC 4.8.2. https://packages.ubuntu.com/trusty/gcc
I mean that it builds on OSX on travis, so presumably the recipe in .travis.yml plus the system version would help clarify what's going on. Builds on Ubuntu have been pretty reliable thanks to apt.
Ah, getting my threads crossed. Any thoughts on this build failure on Ubuntu 16.04 on CircleCI? https://github.com/brewsci/homebrew-bio/pull/179#issuecomment-377671793
Did the libtool deadlock(?) while building gperftool ever get resolved? Or did we work out if it happens in a vg-free gperftool build?
Building gperftools 2.7 on Ubuntu 16.04 on CircleCI does not deadlock. I'd prefer to use this existing version of gperftools with vg if possible rather than compiling the version included with vg.
