> this is different when X uses fltk *and* X11 directly (as apparently > the case in your app), then it *must* link against both directly and > not rely on indirect linkage.
This is the same I was referring to, as we are using more than stock FLTK. FLTK tries hard to deduce what libraries will use (including their paths) and EDE explores that: if FLTK was compiled with Xft, EDE could direcly use Xft API. Without those informations, I would have to duplicate FLTK configure script; otherwise, fltk-config solved this before (no matter if FLTK was compiled as static library, which is often done, or dynamic, since --ldflags was giving a unified interface). Now, --ldstaticflags doesn't work either as it will list dependencies, but put full path to static library, so this: g++ foo.cpp -o foo `fltk-config --cflags --ldstaticflags` doesn't work. >> Dynamic linker knows nothing if there are missing symbols and unless >> compiler is provided with needed shared library. Also, we are not >> using libtool (yet) so there are no .la files to resolve dependencies. > there are no missing symbols in proper shared libraries, so there is > no problem. I was talking about the binary itself, not shared library; but thanks for brief explanation :) > Also it might shock you to hear, la files are not the "solution", > debian removes these too Cool, now we can expect broken libtool and ltdl? ;) Joke aside, EDE never used libtool and .la files are dumped by jam build just for convinience. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1007429 Title: FLTK fltk-config tool is broken To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fltk1.3/+bug/1007429/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
