COIN-OR::LEMON - Graph Library

Custom Query (545 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (109 - 111 of 545)

Ticket Resolution Summary Owner Reporter
#480 fixed Another clang compatibility issue Alpar Juttner Alpar Juttner
Description

Yongjia Song, from lemon-user:

I checked these two version out, however, I still have compiling issues below:

In file included from /Users/administrator/Downloads/lemon-main-62dba6c90f35/tools/lgf-gen.cc:31:

In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:593:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/utility:221:9: error: 

      field has incomplete type '_delaunay_bits::BeachIt'

    _T2 second;

        ^

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__tree:602:16: note: 

      in instantiation of template class 'std::__1::pair<double,

      _delaunay_bits::BeachIt>' requested here

    value_type __value_;

               ^

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__tree:624:22: note: 

      in instantiation of template class

      'std::__1::__tree_node<std::__1::pair<double, _delaunay_bits::BeachIt>,

      void *>' requested here

    typedef typename __node::base                                 __node_base;

                     ^

[...]

-- Sincerely: SONG Yongjia(宋永佳)

#481 fixed Shared library build is broken with glpk Alpar Juttner amluto
Description

If I configure with:

cmake .. -DBUILD_SHARED_LIBS:BOOL=ON -DLEMON_ENABLE_GLPK=YES

then the build fails with lots of errors about undefined glp_ symbols.

The library link line is missing -lglpk. I'd submit a patch, but my cmake-foo isn't very good.

Running:

LDFLAGS=-lglpk cmake .. -DBUILD_SHARED_LIBS:BOOL=ON -DLEMON_ENABLE_GLPK=YES

works around the problem, but that's gross.

#482 fixed Consider giving libemon.so a real soname when building a shared library Alpar Juttner amluto
Description

Hi-

I'm playing with packaging lemon for Fedora. Currently everything works (as long as I don't try to link against glpk), but the resulting libemon.so doesn't have an associated version. This will cause issues when lemon gets upgraded.

Would you be willing to version it for real or at least to create libemon-1.3.so and symlink it to libemon.so? (The latter is a bit annoying in that it will force all users to rebuild for each new major release, but it's better than causing silent failures.)

Thanks!

Note: See TracQuery for help on using queries.