Hi,
Thanks for your support, m here trying to cross compile fltk 1.1.9 for arm
target board, finally m getting error is shown below
/home/vinayak/arm-2007q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.2.0/../../../../arm-none-linux-gnueabi/bin/ld:
cannot find -lXext
collect2: ld returned 1 exit
Now that the FLTK-1.3.x documentation is being restructured to use
doxygen, would it be worth while to introduce two, or possibly three
new chapters or appendices:
a. Frequently Asked Questions:
Although the web site has an Articles FAQs page, the interface
is a little awkward and it is
Duncan Gibson wrote:
Now that the FLTK-1.3.x documentation is being restructured to use
doxygen, would it be worth while to introduce two, or possibly three
new chapters or appendices:
a. Frequently Asked Questions:
+2 ;-)
b1.Build environments:
One paragraph per build environment or
+1 for resizing
+1 for (raw) image (data) handling
Some howtos already exist for these topics... How easy is it to absorb
them into the doxygen? (I have no knowledge of how doxygen works with
this...)
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher
Please read:
As I'm not sure it is a good idea to remove Xext, my question would be :
Is there a configuration case where we need this libXext at link time ?
Fabien
___
fltk-dev mailing list
fltk-dev@easysw.com
Removing the X11/Intrinsinc.h worked well on both Fedora 4
and recent Ubuntu 8.04
This said, there are two things to report:
1. Removing this including should also be followed by a
string.h include in replacement as otherwise, we don't get
the memcpy prototype declaration at least on
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I'm not to bothered about Fl_Scroll, but this I do care about...
But I don't think that having utf-8 doesn't affect anybody's
code. In my
german language code there are lots of german Umlauts
(äöüÄÖÜ) and the
sharp s (ß) that don't display
Anyway - returning to the question at hand... Do we actually need Xext
or not?
I'm not even clear as to what it provides!
I'm not a unix X11 geek too, so I used the nm tool on libXext to look at the
APIs listing, then used grep to look if we used some extensions prefix and it
seems that (at
Anyway - returning to the question at hand... Do we
actually need Xext
or not?
I'm not even clear as to what it provides!
I'm not a unix X11 geek too, so I used the nm tool on libXext
to look at the APIs listing, then used grep to look if we
used some extensions prefix and it seems
OK, this is interesting... Does it fail to render the
ISO-8859-1 characters on all platforms, or is it only on linux?
There's something I saw in the linux parts of my utf8 code
that might be implicated here... But if it isn't working on
OSX or win32 either it may be a more general
MacArthur, Ian (SELEX GALILEO, UK) wrote:
OK, this is interesting... Does it fail to render the
ISO-8859-1 characters on all platforms, or is it only on linux?
There's something I saw in the linux parts of my utf8 code
that might be implicated here... But if it isn't working on
OSX or
Hi,Thanks for your response, but still m having small doubts i hope u will
clear that..as per your suggestion, there is no file like libXext.and
libXext.so in cross compile environment, but it is there in host environment in
/usr/lib.my question is how to obtain libXext.so??? and where to
as per your suggestion, there is no file like libXext.and
libXext.so in cross compile environment, but it is there
in host environment in /usr/lib.
my question is how to obtain libXext.so???
If it is not there, it is probable that the X-server for your target
platform does not provide those
+ on all of them as long as the documentation stays structured. We
have README files on OS issues, but most IDE's exist only for single
OS, so it probably makes sense to merge this information. There is a
lot to say about the Xcode IDE support for FLTK for example... ;-)
On 24.09.2008, at
14 matches
Mail list logo
