patrickfrey / strusbase Goto Github PK

NumericVariant:

    /// \brief Cast to an unsigned integer
    double tofloat() const
    {
        return cast<double>();
    }

applies to all strus packages.

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DLIB_INSTALL_DIR=lib .

Then I see:

cd strusUtilities_explicit_document_type/src/utils && /bin/c++
 -IstrusUtilities_explicit_document_type/include  -std=c++98
 -Wall -pedantic -g -Wfatal-errors -fvisibility=hidden -fPIC -O3 -pthread -O3 -DNDEBUG 
-o CMakeFiles/strusutilities_private_utils.dir/utils.cpp.o -c src/utils/utils.cpp

O3 is there twice, once with the STRUS_OPTIMIZATION_LEVEL and once because cmake
sets it when Release is given.

When using:

 cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DLIB_INSTALL_DIR=lib .

I see:

cd strusUtilities_explicit_document_type/src/utils && /bin/c++ 
 -IstrusUtilities_explicit_document_type/include
 -std=c++98  -Wall -pedantic -g -Wfatal-errors -fvisibility=hidden -fPIC -O3
-pthread -g   -o CMakeFiles/strusutilities_private_utils.dir/utils.cpp.
 -c strusUtilities_explicit_document_type/src/utils/utils.cpp

Debug and O3 are not good friends. ;-)

If I add my own compilation flags, they are simply ignored.

So STRUS_OPTIMIZATION_LEVEL should be removed

and

set( CMAKE_CXX_FLAGS "-std=c++98  -Wall -pedantic -g -Wfatal-error
-fvisibility=hidden -fPIC ...

should be changed to

set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++98  -Wall -pedantic
-g -Wfatal-errors -fvisibility=hidden -fPIC ...

See also http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/, "Clobbering CMAKE_CXX_FLAGS".

At least tested on FreeBSD 10.3 on SPARCH64. Boost is broken, see

boostorg/context@f2ef6326b6ed

If there are efforts to fix Boost for SPARC, then yes, support can continue.

We rely on boost_atomic..

ld.conf.d/strus.conf should only be in the lowest package "strusBase", currently it is in "strus".

readelf -d

shows that we have an RPATH to /usr/lib/strus

So, when building tests on a machine having strus libraries installed, those installed libraries
take precedence and not the once you are currently working on. This should be either
a RUNPATH or no RPATH/RUNPATH at all.

Also package maintainers don't like RPATHs in packages.

I fail to see how this could possibly work, all references to the libraries to link to are specidfied without
"_d".

Besides it's better IMHO to do separate builds for Release and Debug outside the source tree in
dedicated build directories (out-of-source-builds).

This applies to all strus repositories.

We get:

src/error/libstrus_error.so -> libstrus_error.so.0.10
src/error/libstrus_error.so.0.10
src/error/libstrus_error.so.0.10.0

Where libstrus_error.so.0.10 gets a dependency on strusbase:

 0x00000001 (NEEDED)                     Shared library: [../base/libstrus_base.so.0.10]

And libstrus_error.so.0.10.0:

 0x00000001 (NEEDED)                     Shared library: [libstrus_base.so.0.10]

The first one is completely wrong.

This bug applies to all strus projects.

As many files created by cmake are ignored in .gitignore, make distclean doesn't delete them.
(examples CMakeFiles directory, Makefile, cmake_install.cmake, etc.)

Applies to all strus projects.

Quite some things are superfluous and should be removed IMHO:

• set( CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON ), we use native packages, not cpack
• probing of Linux distribution (if the build process starts to depend on the Linux distribution we
  are in real trouble)
• ARGS -Rf pkg ${DISTCLEANED}, pkg is from cpack presumably

Applies to all strus projects.

Linking CXX shared library libstrus_base.so
/usr/bin/ld: ../utils/libstrusbase_private_utils.a(utils.cpp.o): relocation R_X86_64_32 against `_ZNSt3__15ctypeIcE2idE' can not be used when making a shared object; recompile with -fPIC
../utils/libstrusbase_private_utils.a: could not read symbols: Bad value
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

c++filt _ZNSt3__15ctypeIcE2idE

says:

std::__1::ctype<char>::id

Why should default symbols in the c libary be non-PIC I wonder?

A variety of issues:

• make dist doesn't work in an out-of-source builds
• dito deploy_to_obs.sh
• deploy_to_obs.sh is very Linux-focused, doesn't work on non-Linux (arguments, md5sum, etc.)

This applies to all strus projects.

The project version has nothing to do with the API/ABI version of a shared library, so
not the same variables should be used in:

set_target_properties(
    strus_error
    PROPERTIES
    DEBUG_POSTFIX "_d"
    SOVERSION "${STRUS_MAJOR_VERSION}.${STRUS_MINOR_VERSION}"
    VERSION ${STRUS_VERSION}
)

SONAME should be an increasing integer indicating whether the binary compatibility of
the library has been changed. VERSION is used to create the symlinks when installing
for loaders which are not smart enough.

This applies to all strus projects.

OpenSuseBuild service builds and Travis builds can be organized using Github hooks.
This would produce a new version of the master for Linux and OSX.
FreeBSD, OpenBSD would remain manual builds (there is no automatized build system I know
of, which would support those two platforms).

Travis has a cancel-build-feature: if a new master is built and the current builds are aborted
if there is a new check-in on Github.
OBS has this feature since ever.
So we don't have to worry to use too many resources on those build systems.

The current way of manually building OBS versions leads to tedious repetitive work or/and
non-current packages.

Also the Travis CI and OBS builds run on my personal accounts, which makes them most
likely invisible to users.