[med-svn] [Git][med-team/libmmmulti][master] 2 commits: Link Dynamically

[Nilesh Patra]

Nilesh Patra pushed to branch master at Debian Med / libmmmulti


Commits:
08ff8a7d by Nilesh Patra at 2020-10-26T18:52:18+00:00
Link Dynamically

- - - - -
36063859 by Nilesh Patra at 2020-10-26T18:52:40+00:00
Modify Install file

On a look at it, all code actually resides in the "header files" - the
main.cpp just contains a main function which is basically the logic for
the mmmulti binary.

The header files do _not_ seem to be used in the standard way wherein
headers contains mostly the prototypes and the corresponding c/cpp files
contain the definitions and declarations. This is also apparent by the
this package's documentation.

Hence it might be a good idea to simply make it header only (plus installing
corresponding binary) and use it in a way that it's intended to.
That being said, what I did there might be _completely wrong_ consider to revert
this commit if so

- - - - -


6 changed files:

- debian/control
- debian/libmmmulti-dev.install
- − debian/libmmmulti0.dirs
- − debian/libmmmulti0.install
- − debian/mmmulti-dev.dirs
- debian/patches/NoExternalSourceTrees.patch


Changes:

=====================================
debian/control
=====================================
@@ -51,34 +51,3 @@ Description: header files for mmmulti library
  we are virtually guaranteed to be able to complete the compute.
  .
  This package contains header files and the static library
-
-Package: libmmmulti0
-Architecture: any
-Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Description: memory-mapped multimap, multiset, and interval tree
- Sometimes you have a lot of plain-old data, but you need random access
- to it. These header-only classes combine memory-mapped files with
- high-performance parallel sorting and appropriate indexing strategies
- to support very large (>memory but <disk) multimaps, multisets, and
- interval trees.
- .
- This implements a memory backed multimap intended for use where:
-  * your keys are integers, or can be mapped to dense range of integers,
-  * the memory mapped file is on fast storage, like an SSD (although
-    this is not a requirement),
-  * you have arbitrary values of fixed size (e.g. structs, other POD
-    types) that can be sorted,
-  * you don't need dynamic updates of the table,
-  * and you are likely to run out of memory of you use a traditional
-    map or hash table,
-  * but you can handle approximately 1 bit per record in RAM.
- .
- These may seem to be very specific, but many problems can be mapped into
- a dense integer set. mmmulti::map developed first as a data structure
- to support seqwish, which uses it to generate precise variation graphs
- from pairwise alignments between collections of sequences. As this
- multimap forms a key data processing kernel in the algorithm, it can
- scale to extremely large problem sizes, limited only by available disk
- space. Although performance is much slower than an in-memory structure,
- we are virtually guaranteed to be able to complete the compute.


=====================================
debian/libmmmulti-dev.install
=====================================
@@ -1,4 +1,2 @@
-usr/include/*
-usr/lib/*/lib*.so
-usr/lib/*/pkgconfig/*
-usr/share/pkgconfig/*
+bin/*		usr/bin
+src/*.hpp	usr/include


=====================================
debian/libmmmulti0.dirs deleted
=====================================
@@ -1 +0,0 @@
-usr/lib


=====================================
debian/libmmmulti0.install deleted
=====================================
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*


=====================================
debian/mmmulti-dev.dirs deleted
=====================================
@@ -1,2 +0,0 @@
-usr/lib
-usr/include


=====================================
debian/patches/NoExternalSourceTrees.patch
=====================================
@@ -1,6 +1,17 @@
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
-@@ -22,110 +22,22 @@ set(LIBRARY_OUTPUT_PATH ${CMAKE_SOURCE_D
+@@ -11,8 +11,8 @@
+ find_package(Threads REQUIRED)
+ 
+ # Use all standard-compliant optimizations
+-set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O3 -mcx16 -g")
+-set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3 -mcx16 -g")
++set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -O3 -g -fPIC -fopenmp")
++set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3 -g -fPIC -fopenmp")
+ 
+ # Set the output folder where your program will be created
+ set(CMAKE_BINARY_DIR ${CMAKE_SOURCE_DIR}/bin)
+@@ -22,110 +22,22 @@
  # The following folder will be included
  include_directories("${PROJECT_SOURCE_DIR}")
  
@@ -119,7 +130,7 @@
    
  # macOS doesn't want you to link in libatomic this way
  if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
-@@ -137,9 +49,9 @@ if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin
+@@ -137,9 +49,9 @@
      )
  elseif (TRUE)
    target_link_libraries(mmmulti
@@ -132,3 +143,12 @@
      "-latomic"
      Threads::Threads
      )
+@@ -150,7 +62,7 @@
+ elseif (TRUE)
+   # this was hard to track down
+   # https://stackoverflow.com/questions/35116327/when-g-static-link-pthread-cause-segmentation-fault-why
+-  set(CMAKE_EXE_LINKER_FLAGS "-static -Wl,--whole-archive -lpthread -Wl,--no-whole-archive")
++  set (CMAKE_SHARED_LINKER_FLAGS "-lpthread -Wl,--as-needed")
+ endif()
+ 
+ 



View it on GitLab: https://salsa.debian.org/med-team/libmmmulti/-/compare/c2a7285114b8709ec4a76734b9b9543c817581b2...360638594a1921b4dc75fd68a5249d6f774997cf

-- 
View it on GitLab: https://salsa.debian.org/med-team/libmmmulti/-/compare/c2a7285114b8709ec4a76734b9b9543c817581b2...360638594a1921b4dc75fd68a5249d6f774997cf
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-commit/attachments/20201026/04bae593/attachment-0001.html>