| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
| |
|
|
| |
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
| |
|
|
|
| |
Package-Manager: Portage-3.0.30, Repoman-3.0.3
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
| |
|
|
|
| |
Package-Manager: Portage-3.0.28, Repoman-3.0.3
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
| |
|
|
|
| |
Package-Manager: Portage-3.0.22, Repoman-3.0.3
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
| |
|
|
|
| |
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
| |
|
|
|
| |
Package-Manager: Portage-3.0.13, Repoman-3.0.2
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@riseup.net>
|
| |
|
|
|
| |
Package-Manager: Portage-3.0.13, Repoman-3.0.2
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@riseup.net>
|
| |
|
|
|
| |
Package-Manager: Portage-3.0.12, Repoman-3.0.2
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@riseup.net>
|
| |
|
|
|
|
| |
Closes: https://github.com/gentoo/sci/pull/1014
Package-Manager: Portage-3.0.12, Repoman-3.0.2
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@riseup.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add more regexps specifying which parts of the test suite should
not be compiled at all.
We have so far problems with say ncbi-tools++-18.0.0 libs installed
in ${EPREFIX}/usr/lib64/ncbi-tools++/ which get picked during linking
of a currently emerged package, like ncbi-tools++-22.0.0. That happens
due to LDPATH being set through
```
echo "LDPATH=${EPREFIX}/usr/$(get_libdir)/${PN}" > ${S}/99${PN}
doenvd "${S}/99${PN}"
```
which results in
```
$ cat /etc/env.d/99ncbi-tools++
LDPATH=/usr/lib64/ncbi-tools++
$
```
and later used during linking of a future version. Some symbols will be
resolved by ${EPREFIX}/usr/lib64/ncbi-tools++/ from older version,
some probably not. It is confusing to debug the errors popping up
during compilation/linking.
Aaron Ucko from NCBI proposed:
To avoid interference from old installations, please try passing
`LDFLAGS=-Wl,-rpath-link,"${S}"_build/lib` to configure, no patches
(likely) needed.
@kiwifb François Bissey commented with:
<quote>
LDPATH is used to generate the ld.so.conf.d files. So it is important
to have it to be able to find the libraries that are not in a standard
path. LDPATH is a Gentoo special. You need to regenerate the cache with
ldconfig after installing such a library and such a path.
...
$ /usr/bin/x86_64-pc-linux-gnu-g++ -std=gnu++11 -Wl,--verbose
-Wl,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0
-Wl,--enable-new-dtags -Wl,-export-dynamic -pthread -Wl,-O1
-Wl,--as-needed -g speedtest.o
-L/scratch/var/tmp/portage/sci-biology/ncbi-tools++-22.0.0/work/\
ncbi_cxx--22_0_0_build/lib
-lprosplign -lxalgoalignutil -ltaxon1 -lxalgoseq -lxcleanup
-lxobjedit -ltaxon3 -lvalid -lvalerr -lproteinkmer -lxblast
-lxalgoblastdbindex -lcomposition_adjustment -lxalgodustmask
-lxalgowinmask -lseqmasks_io -lseqdb -lblast_services -lxalnmgr
-lxobjutil -lxobjread -lvariation -lcreaders -lsubmit -lxnetblastcli
-lxnetblast -lblastdb -lscoremat -ltables -lxqueryparse -lxregexp
-lncbi_xloader_genbank -lncbi_xreader_id1 -lncbi_xreader_id2
-lncbi_xreader_cache -ldbapi_driver -lncbi_xreader -lxconnect
-lid1 -lid2 -lxobjmgr -lgenome_collection -lseqedit -lseqsplit
-lsubmit -lseqset -lseq -lseqcode -lsequtil -lpub -lmedline
-lbiblio -lgeneral -lxser -lxutil -lxncbi -lxcompress -lz -lbz2
-llzo2 -lz -lnsl -ldl -lpcre -llmdb -lpthread -ldw -ldl -lm
-lpthread -o speedtest
It cannot find libmlacli.so. Note that there isn’t a `-lmlacli`
anywhere in the above line. It is searched for because you are
compiling an executable and executable cannot have unresolved
symbols. It must in the table of needed libraries for libxobjedit.so
libmlacli.so needed by /scratch/var/tmp/portage/sci-biology/\
ncbi-tools++-22.0.0/work/ncbi_cxx--22_0_0_build/lib/libxobjedit.so
Because there is no path or possibly a final path in libxobjedit.so
that library cannot be found.
Two solutions here:
1) add -lmlacli in the compilation line above
2) Precede the whole line with
LD_LIBRARY_PATH=/scratch/var/tmp/portage/sci-biology/\
ncbi-tools++-22.0.0/work/ncbi_cxx--22_0_0_build/lib
The LDPATH setting probably enabled you to find a previously
installed version of the library.
François
PS: You can pass that analysis upstream because -lmlacli should
probably be added by right.
</quote>
Later François also wrote:
<quote>
rpath are usually the preferred solution but it is not the end all
solution. Looking for LDPATH in your /etc/env.d/ may shock you.
In the case of ncbi, adding path is only one of the solution I
would consider. I don’t see why they need to install in
/usr/lib{,64}/ncbi-tools++ rather than just /usr/lib{,64} in
the first place. It is not even versioned to allow several versions
installed in parallel. It is not plugins or “modules” or other
special kinds of shared objects.
Possibly it is some language runtime - at best. Does it use names
that could collide easily with something else? May be some of them
should be prefixed then.
</quote>
make[3]: Entering directory '/scratch/var/tmp/portage/sci-biology/\
ncbi-tools++-22.0.0/work/ncbi_cxx--22_0_0_build/build/app/speedtest'
Updating dependency information for /scratch/var/tmp/portage/sci-biology/\
ncbi-tools++-22.0.0/work/ncbi_cxx--22_0_0/src/app/speedtest/speedtest.cpp.
/usr/bin/x86_64-pc-linux-gnu-g++ -std=gnu++11 -c -Wall -Wno-format-y2k
-pthread -pipe -mpclmul -mpopcnt -march=native -ftree-vectorize -fPIC
-g -D_DEBUG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
-D_MT -D_REENTRANT -D_THREAD_SAFE
-I/scratch/var/tmp/portage/sci-biology/ncbi-tools++-22.0.0/work/\
ncbi_cxx--22_0_0_build/inc
-I/scratch/var/tmp/portage/sci-biology/ncbi-tools++-22.0.0/work/\
ncbi_cxx--22_0_0/include
/scratch/var/tmp/portage/sci-biology/ncbi-tools++-22.0.0/work/\
ncbi_cxx--22_0_0/src/app/speedtest/speedtest.cpp
-o speedtest.o
/usr/bin/x86_64-pc-linux-gnu-g++ -std=gnu++11
-Wl,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0
-Wl,--enable-new-dtags -Wl,-export-dynamic -pthread -Wl,-O1
-Wl,--as-needed -g speedtest.o
-L/scratch/var/tmp/portage/sci-biology/ncbi-tools++-22.0.0/work/\
ncbi_cxx--22_0_0_build/lib
-lprosplign -lxalgoalignutil -ltaxon1 -lxalgoseq -lxcleanup -lxobjedit
-ltaxon3 -lvalid -lvalerr -lproteinkmer -lxblast -lxalgoblastdbindex
-lcomposition_adjustment -lxalgodustmask -lxalgowinmask -lseqmasks_io
-lseqdb -lblast_services -lxalnmgr -lxobjutil -lxobjread -lvariation
-lcreaders -lsubmit -lxnetblastcli -lxnetblast -lblastdb -lscoremat
-ltables -lxqueryparse -lxregexp -lncbi_xloader_genbank -lncbi_xreader_id1
-lncbi_xreader_id2 -lncbi_xreader_cache -ldbapi_driver -lncbi_xreader
-lxconnect -lid1 -lid2 -lxobjmgr -lgenome_collection -lseqedit -lseqsplit
-lsubmit -lseqset -lseq -lseqcode -lsequtil -lpub -lmedline -lbiblio
-lgeneral -lxser -lxutil -lxncbi -lxcompress -lz -lbz2 -llzo2 -lz -lnsl
-ldl -lpcre -llmdb -lpthread -ldw -ldl -lm -lpthread -o speedtest
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/\
bin/ld: warning: libmlacli.so, needed by /scratch/var/tmp/portage/\
sci-biology/ncbi-tools++-22.0.0/work/ncbi_cxx--22_0_0_build/lib/\
libxobjedit.so, not found (try using -rpath or -rpath-link)
The problem here is that the rpath would have to be provided when
you link libxobjedit.so. I checked the log and it wasn’t done.
And you definitely don’t want to do that unless you re-link without
the rpath (or the correct final rpath) at install time. For information
cmake does exactly that.
But in the end adding a path in this case is no substitute to providing
the libraries you need. When building stuff with libtool, libtool produces
test scripts that set LD_LIBRARY_PATH properly for running the tests before
install. So the test executables don’t have to be linked with rpath to
the build folder. Or the objects that you want to ship either.
</quote>
This change will ensure `LDFLAGS=-Wl,-rpath-link,"${S}"_build/lib` is
passed to `bash ./src/build-system/configure` in `src_configure()`
and at least helps to get symbols resolved during linking although it
is probably still far from ideal.
Package-Manager: Portage-2.3.62, Repoman-2.3.12
Signed-off-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have the following defined due to ncbi-tools++-18.0.0 installed
on my system:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/32:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/32:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0:
/usr/lib/llvm/7/lib32:
/usr/lib/llvm/7/lib64:
/usr/lib64/itcl4.1.1:
/usr/lib64/itk4.1.0:
/lib64:
/usr/lib64:
/usr/local/lib64:
/lib32:
/usr/lib32:
/usr/lib64/rust-1.29.2:
/usr/lib64/R/lib:
/usr/lib64/fltk:
/usr/lib64/ncbi-tools++:
/usr/lib64/staden:
grep: /etc: No such file or directory
grep: /etc/env.d: No such file or directory
/etc/env.d/99ncbi-tools++:LDPATH=/usr/lib64/ncbi-tools++
...
That in turn makes linker pick "${WORKDIR}"/ncbi_cxx--22_0_0_build/lib/*
files but later overrides some of them with /usr/lib64/ncbi-tools++/*,
depending on the ordering of -lXXXXXX arguments.
Package-Manager: Portage-2.3.62, Repoman-2.3.12
Signed-off-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
|
|
|
It does not link if older version is installed because linker
picks up older version of libraries and obviously does not find
newly added functions.
Upstream says:
Please try either supplying an LD_RUN_PATH environment setting
or a -Wl,-rpath-link,... flag pointing at your build tree's lib
directory. Also, please bear in mind that adding the old
installation's library directory to the central search path largely
defeats the purpose of making it a separate directory.
Package-Manager: Portage-2.3.62, Repoman-2.3.12
Signed-off-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
|
Andrew Ammerlaan
Andrew Ammerlaan
Martin Mokrejs
GitWeb