Closed MichelMoser closed 3 years ago
I haven't compiled with boost. Can you figure out how to disable that aspect of the build?
On Thu, Nov 5, 2020, 10:25 MichelMoser notifications@github.com wrote:
hi,
I am trying to compile edyeet and run into some problems with the --wrap=memcpy option.
install commands:
module load zlib/1.2.11-GCCcore-8.3.0 module load Boost/1.71.0-gompi-2019b module load GCC/8.3.0 cd edyeet ./bootstrap.sh ./configure --prefix=$PWD --with-boost=/cluster/software/Boost/1.71.0-gompi-2019b/ make
output:
checking for g++... g++ checking whether the C++ compiler works... yes checking for C++ compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking boost/math/distributions/binomial.hpp usability... yes checking boost/math/distributions/binomial.hpp presence... yes checking for boost/math/distributions/binomial.hpp... yes configure: creating ./config.status config.status: creating Makefile
make
g++ -O3 -DNDEBUG -g -std=c++14 -Wno-deprecated-declarations -Isrc -I /cluster/software/Boost/1.71.0-gompi-2019b//include -include src/common/memcpyLink.h -Wl,--wrap=memcpy -DUSE_BOOST src/yeet/yeet_main.cpp -o edyeet /cluster/software/Boost/1.71.0-gompi-2019b//lib/libboost_math_c99.a -lstdc++ -lz -lm -lpthread /net/10.222.0.31/projects01/Orion/cluster/software/GCCcore/8.3.0/include/c++/8.3.0/bits/stl_algobase.h:368: error: undefined reference to 'wrap_memcpy' /net/10.222.0.31/projects01/Orion/cluster/software/GCCcore/8.3.0/include/c++/8.3.0/bits/stl_algobase.h:368: error: undefined reference to 'wrap_memcpy' /net/10.222.0.31/projects01/Orion/cluster/software/GCCcore/8.3.0/include/c++/8.3.0/bits/stl_algobase.h:368: error: undefined reference to 'wrap_memcpy' /net/10.222.0.31/projects01/Orion/cluster/software/GCCcore/8.3.0/include/c++/8.3.0/bits/char_traits.h:352: error: undefined reference to 'wrap_memcpy' collect2: error: ld returned 1 exit status make: *** [edyeet] Error 1
I tried augmenting the src/common/memcpyLink.h file according to a similar issue in MashMap: marbl/MashMap#10 https://github.com/marbl/MashMap/issues/10 but resulting binary is not responding.
Help would be appreciated.
Thanks, Michel
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ekg/edyeet/issues/6, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABDQEJE7FODYWFWRYB6WQDSOJVQTANCNFSM4TLDNUXQ .
i switched to GSL, but same error occurs.
make
g++ -O3 -DNDEBUG -g -std=c++14 -Wno-deprecated-declarations -Isrc -I /cluster/software/GSL/2.5-GCC-7.3.0-2.30//include -include src/common/memcpyLink.h -Wl,--wrap=memcpy src/yeet/yeet_main.cpp -o edyeet -L/cluster/software/GSL/2.5-GCC-7.3.0-2.30//lib -lgsl -lgslcblas -lstdc++ -lz -lm -lpthread
/net/10.222.0.31/projects01/Orion/cluster/software/GCCcore/7.3.0/include/c++/7.3.0/bits/char_traits.h:350: error: undefined reference to '__wrap_memcpy'
src/common/edlib.hxx:1364: error: undefined reference to '__wrap_memcpy'
src/common/edlib.hxx:1365: error: undefined reference to '__wrap_memcpy'
src/common/edlib.hxx:307: error: undefined reference to '__wrap_memcpy'
collect2: error: ld returned 1 exit status
make: *** [edyeet] Error 1
Should GCC version match the version mentioned in src/common/memcpyLink.h?
cat src/common/memcpyLink.h
/**
* @file memcpyLink.h
* @author Chirag Jain <cjain7@gatech.edu>
*/
__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
Uh oh. I wonder if that's the problem. Would you please check if setting the correct GCC version here fixes the build?
On Thu, Nov 5, 2020, 11:34 MichelMoser notifications@github.com wrote:
i switched to GSL, but same error occurs.
make g++ -O3 -DNDEBUG -g -std=c++14 -Wno-deprecated-declarations -Isrc -I /cluster/software/GSL/2.5-GCC-7.3.0-2.30//include -include src/common/memcpyLink.h -Wl,--wrap=memcpy src/yeet/yeet_main.cpp -o edyeet -L/cluster/software/GSL/2.5-GCC-7.3.0-2.30//lib -lgsl -lgslcblas -lstdc++ -lz -lm -lpthread /net/10.222.0.31/projects01/Orion/cluster/software/GCCcore/7.3.0/include/c++/7.3.0/bits/char_traits.h:350: error: undefined reference to 'wrap_memcpy' src/common/edlib.hxx:1364: error: undefined reference to '__wrap_memcpy' src/common/edlib.hxx:1365: error: undefined reference to 'wrap_memcpy' src/common/edlib.hxx:307: error: undefined reference to '__wrap_memcpy' collect2: error: ld returned 1 exit status make: *** [edyeet] Error 1
Should GCC version match the version mentioned in src/common/memcpyLink.h?
cat src/common/memcpyLink.h
/**
- @file memcpyLink.h
- @author Chirag Jain cjain7@gatech.edu */
asm(".symver memcpy,memcpy@GLIBC_2.2.5");
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ekg/edyeet/issues/6#issuecomment-722291256, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABDQEOYMYVIP5WCXLQTCN3SOJ5R3ANCNFSM4TLDNUXQ .
hmm, no this did not solve the problem.
Could you share your compilation settings and commands for edyeet? So i can maybe backtrack the error.
I am on a Centos 7.8 node on a cluster. Maybe using a container would be better?
tried building the container based on the Dockerfile at pggb repo.
edyeet compiled successfully, but smoothxg is missing some files. probably some error introduced in the latest push?
Hi Michel, thanks for reporting that the current Dockerfile of pggb is broken. Currently taking a look at it.
great, thank you!
Was able to reproduce you the issue locally. Now trying a fix.
The Dockerfile in current master of pggb should work now. I tested it locally and in a Ubuntu VM. Please try it out :) Or just wait, until the container was built.
great, we will test and report back
successfully built the container and ran the test dataset of pggb. Thank you very much!
actually, smoothxg is failing because its missing an output option -o which can not be set within pggb
[seqwish::links] 0.439 links derived
[seqwish::gfa] 0.439 writing graph
[seqwish::gfa] 0.473 done
seqwish -t 16 -s /mnt/users/michelmo/tools/pggb/data/HLA/DRB1-3123.fa.gz -p /mnt/users/michelmo/tools/pggb/data/HLA/DRB1-3123.fa.gz.pggb-s3000-p70-n10-a70-K16-k8-w10000-j5000-e5000.paf -k 8 -g /mnt/users/michelmo/tools/pggb/data/HLA/DRB1-3123.fa.gz.pggb-s3000-p70-n10-a70-K16-k8-w10000-j5000-e5000.seqwish.gfa -P
0.33s user 0.19s system 90% cpu 0.59s total 26144Kb max memory
[smoothxg::main] error: Please specify an output file with -o/--smoothed-out
Command exited with non-zero status 1
smoothxg -t 16 -g /mnt/users/michelmo/tools/pggb/data/HLA/DRB1-3123.fa.gz.pggb-s3000-p70-n10-a70-K16-k8-w10000-j5000-e5000.seqwish.gfa -w 10000 -j 5000 -e 5000 -l 10000 -m /mnt/users/michelmo/tools/pggb/data/HLA/DRB1-3123.fa.gz.pggb-s3000-p70-n10-a70-K16-k8-w10000-j5000-e5000.smooth.maf -s /mnt/users/michelmo/tools/pggb/data/HLA/DRB1-3123.fa.gz.pggb-s3000-p70-n10-a70-K16-k8-w10000-j5000-e5000.consensus -a -C 10,100,1000,10000
0.00s user 0.05s system 96% cpu 0.05s total 2484Kb max memory
so smoothxg currently has to be run as a separate final step. But that's no big issue
Hmm, it should work.
We set -o
https://github.com/pangenome/pggb/blob/c3cfcc9e4468928d8ca43cae759577cdb6e9d1d6/pggb#L196.
Could it be that you didn't check out the latest master? Not sure, how I could reproduce your error.
-O2 ?
hi,
I am trying to compile edyeet and run into some problems with the --wrap=memcpy option.
install commands:
output:
I tried augmenting the src/common/memcpyLink.h file according to a similar issue in MashMap: https://github.com/marbl/MashMap/issues/10 but resulting binary is not responding.
Help would be appreciated.
Thanks, Michel