> Didn't Julian Taylor mention 2006? (see link above). I don't know
My bad; Launchpad fonts made 6 looks almost like 8 in my browser
but this makes things even worse :D
> of such a patch, but this is really a long time. He also suggested
> that you should ask the Debian maintainers...
True, but personally I don't like this ball throwing to others: people
has problems with ubuntu, not debian. Also, knowing how debian handles
non-critical issues, it could take a years to get it in ubuntu back.
> I remember that Aaron Ucko (Debian's FLTK maintainer) posted (a link
> to) the Debian patches for FLTK and I took a look at them. We decided
> to implement a small subset, but everything else was said to be
> Debian-specific and should not be done in FLTK. I can't remember if
> there were patches to fltk-config though.
Personally I don't like how debian handles things: if patches are
refused by upstream, then it should be reflected on package or that
package should be removed (or placed to some testing/experimental
repo). It is common knowledge how they will often modify things
without proper knowledge of the subject.
> My impression is that Julian put some interesting points that can
> be summarized as "if you link dynamically, don't add dependent libs
> to your linker command, since they should be resolved by the libs
> you link with". In clear text: "fltk-config --ldflags" should *not*
> give the X11 libs (and others), since the FLTK *dynamic* lib would
> depend on these, and hence the linker would resolve them anyway.
> He suggests to use --ldstaticflags to get these additional libs.
I agree with this: this is how things should be perfect, but the world
is not perfect...
> IMHO fltk-config was NOT designed to do exactly what (Ubuntu) Julian
> assumes it should do. They (Ubuntu) obviously seem to use fltk-config
> to determine dependencies for their Linux distribution. They further
> seem to presume that FLTK will (always?) be configured with dynamic
> libs (--enable-shared), so that "fltk-config --ldflags" would give
> the linker options for dynamic linking. However, this is not always
> true, and I believe the main error is to use fltk-config for this
> task. But I could also be wrong with this interpretation!
>
> I believe the FLTK team decided to use fltk-config as a platform
> independent tool to be used (among others) in Makefile(s) to output
> *all* libs that need to be linked with, dependent on the platform
> and FLTK's configuration. This *must* include the X11 libs, at least
> if FLTK was configured w/o --enable-shared (and is used for dynamic
> linking).
>
> I'm not sure if we could change it if --enable-shared has been used
> so that we can assume --ldflags is used for dynamic linking only,
> whereas --ldstaticflags is different and would output *ALL* needed
> libs (for static linking). Maybe this is what it was designed for?
> But what if --enable-shared has not been used? Would --ldflags then
> be the same as --ldstaticflags?
Can't agree more.
The thing is how --ldstaticflags will behave the same as if fltk was
compiled as static or shared library. This makes things hard to link
if --ldflags is not uniform with shared or static library. Let me give
you the following scenario for e.g. EDE (but can be applied for any
complex fltk application):
1. normal way (like was done before):
* EDE uses fltk without knowledge how it was compiled: as shared or
static or debug and everything links without problems
* EDE apps uses directly fltk dependencies; it is much easier to
determine if fltk was compiled with Xft support or not (just look
for -lXft library in fltk-config output)
2. ubuntu/debian way:
* shared library: some EDE parts use X11 api, some uses Xext api and
some will use cairo; this forces build scripts to give specific
library explicitly
* static library: --ldflags will return all dependencies and because
of above build scripts explicitly added libraries, duplicates
will arises in linking phase. Some (older) linkers will refuse to
make binary in this case.
* we (including fltk users) will have to hack around various
fltk-config outputs to figure out how to link things if we consider
to use things like shape extension or to save image
* as Julian suggested (which is IMHO wrong): let duplicate various
system checks fltk already done: if right png library installed, if
user have fontconfig and etc. bad bad...
* this will work _only_ on debian/ubuntu/fedora17; everywhere else,
as is used non modified fltk will work as[1] (freebsd, solaris, and
other distros that does not uses debian/fedora repos).
3. mixed way:
* they can modify --libs flag and let leave --ldflags (or add own,
specific flag) which will behave as they want; it is quite easier
to determine from configure script if that flag exists or not, if
fltk app is going to be compiled on ubuntu/debian
> More comments welcome...
>
> Albrecht
Regards,
Sanel
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
