fltk linkage

[corvid]

Do we still have a reason for telling people to stick with
static linkage when building fltk?

I was thinking about what our installation instructions should look like
these days, and how everyone has a decent chance of having a fltk-1.3
package available and it may not be best to tell them to run off and
compile fltk unless fltk-config --version doesn't tell them any good news
and they can't get a pkg... and this led me to wonder about the
necessity/appropriateness of static linking.

All that I found in the archive was me wondering about it last year and
no one replying to me. Well, except this now. I'm replying to me, if that
counts.

[Johannes Hofmann]

Post by corvid

Do we still have a reason for telling people to stick with
static linkage when building fltk?

I was thinking about what our installation instructions should look like
these days, and how everyone has a decent chance of having a fltk-1.3
package available and it may not be best to tell them to run off and
compile fltk unless fltk-config --version doesn't tell them any good news
and they can't get a pkg... and this led me to wonder about the
necessity/appropriateness of static linking.
All that I found in the archive was me wondering about it last year and
no one replying to me. Well, except this now. I'm replying to me, if that
counts.

I would leave the decision to link statically or not to the package
maintainers of the various distros. They will do anyway what they
consider best.

[Jorge Arellano Cid]

Post by corvid

Do we still have a reason for telling people to stick with
static linkage when building fltk?

I was thinking about what our installation instructions should look like
these days, and how everyone has a decent chance of having a fltk-1.3
package available and it may not be best to tell them to run off and
compile fltk unless fltk-config --version doesn't tell them any good news
and they can't get a pkg... and this led me to wonder about the
necessity/appropriateness of static linking.
All that I found in the archive was me wondering about it last year and
no one replying to me. Well, except this now. I'm replying to me, if that
counts.

FWIW, I build in a Debian system now and:

$ ldd dillo
[...]
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000)
libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000)
[...]

I thought this meant it was linked with a shared version of FLTK.
What am I missing?

[corvid]

Post by Jorge Arellano Cid

Post by corvid

Do we still have a reason for telling people to stick with
static linkage when building fltk?

I was thinking about what our installation instructions should look like
these days, and how everyone has a decent chance of having a fltk-1.3
package available and it may not be best to tell them to run off and
compile fltk unless fltk-config --version doesn't tell them any good news
and they can't get a pkg... and this led me to wonder about the
necessity/appropriateness of static linking.
All that I found in the archive was me wondering about it last year and
no one replying to me. Well, except this now. I'm replying to me, if that
counts.

$ ldd dillo
[...]
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f2c3e312000)
libfltk.so.1.3 => /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 (0x00007f2c3dfd0000)
[...]
I thought this meant it was linked with a shared version of FLTK.
What am I missing?

*digs through fltk for a minute*

So it's a matter of whether fltk is configured with --enable-shared, then?

The main page of the website still says "statically-linked by default!",
and all along I've had the impression that it had to do with the form of
how we link in the Makefile.

I guess it makes sense to rm that mention from the website, then.

I could've sworn that it was in our documentation somewhere, too, but I
don't see it anywhere at the moment.

PS I think we will be able to get rid of the warning about --enable-cairo ,
since it doesn't seem to do anything bad with fltk-1.3.