Thanks !!
I can build and link with my application right now with directfb 0.9.20.
Once i ran it on my ARM platform, it crash. I have configured my uclinux to
build with fb device. Is it any other thing i am missing to make it work??
./frescod
=========
em86xx[nfs]# ./frescod
Build timestamp: Aug 10 2005 21:58:20
000010305:
000000005: layers_atshutdown: add @91C8A4DC (from )
000000005: confman_initialise: range checking enabled
000000005: 0 external files defined in resources
000000005: layers_atshutdown: add @91C9E5FC (from )
(!) DirectFB/corGPF: pid(60, <frescod>) text_offset(0x58577fb2) (USER
pc=ea077ff
6 r0=91e1cbb0 r3=91e1cbac sp=91e3fdcc lr=91cff184)
e/system: No system found!
---------------------- DirectFB v0.9.20 ---------------------
(c) 2000-2002 convergence integrated media GmbH
(c) 2002-2003 convergence GmbH
-----------------------------------------------------------
(*) Single Application Core. (2005-08-10 10:25)
(!) [ 60: 0.000] --> Caught signal 11 (unknown origin) <--
SIGSEGV
Regards,
Louis
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Denis Oliver
Kropp
Sent: Thursday, August 11, 2005 4:34 AM
To: Stephen GALLIMORE
Cc: [email protected]
Subject: Re: [directfb-dev] compile error for generating directfbstatic
library
Quoting Stephen GALLIMORE:
> >
> > What about adding a workaround in configure.in?
> >
> > Or there might be a reason why LD is not affected.
> Indeed, we did look at this, the obvious adding
> AC_PROG_LD to configure.in didn't seem to have
> the desired effect. Three of us tried in vain to follow
> the tortuous maze of autoconf, automake and libtool
> to try and work out how _any_ of the TOOL = @TOOL@
> lines get created in the Makefile.in files from the
> Makefile.am templates. Short answer, we gave up
> and decided there were more important things in life!
What a nightmare :)
> However we did begin to wonder if LD simply wasn't
> catered for, as using it directly rather than via gcc
> is very rare. In fact the partial link case is about the
> only one we could think of, and we didn't think
> that was commonly used outside of the kernel build.
Linking objects into a new object using "ld -r" is very
neat for keeping the constructor (not C++) calls alive.
Previously, we've been using the ".a" versions and we had to
manually specify the constructor methods on the command line,
otherwise the stupid linker throws them out, but not with ".o" :-)
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
