Hi,
i am trying to build murka 1) against the debian wheezy version of
lpsolve - I get a link error. With a self build 5.5.2.0 everything
is fine ....

flo@p2:~/Downloads/p/p/murka-1.3.1b-src$ make
Making all in murka
make[1]: Entering directory `/home/flo/Downloads/p/p/murka-1.3.1b-src/murka'
g++  -w -O2 -g0 -ldl -lpthread -s  -o murka murka.o nwerr.o args.o getopt.o misc.o nwclient.o nwst.o fformat.o lp_solve/lpsolve55/bin/ux64/liblpsolve55.a
lp_solve/lpsolve55/bin/ux64/liblpsolve55.a(lp_MDO.o): In function `getMDO':
(.text+0x5ad): undefined reference to `colamd_recommended'
lp_solve/lpsolve55/bin/ux64/liblpsolve55.a(lp_MDO.o): In function `getMDO':
(.text+0x5ef): undefined reference to `colamd_set_defaults'
lp_solve/lpsolve55/bin/ux64/liblpsolve55.a(lp_MDO.o): In function `getMDO':
(.text+0x63c): undefined reference to `colamd'
lp_solve/lpsolve55/bin/ux64/liblpsolve55.a(lp_MDO.o): In function `getMDO':
(.text+0x6b4): undefined reference to `symamd'
collect2: error: ld returned 1 exit status
make[1]: *** [murka] Error 1
make[1]: Leaving directory `/home/flo/Downloads/p/p/murka-1.3.1b-src/murka'
make: *** [all-recursive] Error 1

severity 730124 minor
retitle 730124 doesn't include colamd dunctions, needs extra -lcolamd
tag 730124 + wontfix
thanks

Because that version is broken.

Because in Debian that .a doesn't include those stuff but we do link with
system-colamd. If you used the .so (which exists but is hidden due
to not being SONAMEd) it should have worked fine(tm).

So just install libsuitesparse-dev and link with -lcolamd (and the same for
whatever is symamd)

Regards,

Rene

Hi,

http://packages.debian.org/wheezy/liblpsolve55-dev

FWIW, For exactly that reason liblpsolve55-dev already depends on
libsuitesparse-dev.

Regards,

Rene

So how would i use the "hidden" dynamic so? If i link any application
against it the dynamic linker aka ld.so wont find it.

I had a quick grep and i could find any package in the debian
repository dynamically linking against lpsolve.

Sounds broken for me and compiling my own lpsolve is way easier than
using the debian packages which sounds strange even more.

Flo

Hi,

See e.g. http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=patches/fix-system-lpsolve-build.diff;h=504d206b2e8e232363e271341b32c8dc93713800;hb=HEAD:


.. except you set a rpath, yes.

How? Note the shared lib is *of course* not in liblpsolve55-dev.

A liblpsolve55 package would be buggy (because no SONAME etc..), so
it's hidden in /usr/lib/lp_solve in lp_solve.
The lp_solve binary itself (why linking a whole static liblpsolve55.a in?
Should be dynamically linked).

libreoffice-calc does.

Both lp_solve (lp-solved) and libsolverlo.so (libreoffice-calc) have said
rpath.

No, including a third-party lib into liblpsolve55.a is broken imho.
If you need colamd you need -lcolamd.

We should get rid of such internal code copies (in this case of even a
(quite) unknown version.)

The root cause here is that lpsolve is such a badly library upstream,
if it had e.g. a pkg-config file we could just add -lcolamd there and be
done -> no problem. I could invent one, but that would only help on Debian...

Regards,

Rene