John Tytgat wrote:
: ELF file 'ls,e1f' contains non-static program data which makes it
: unconvertable to AIF
Is that the default autobuilder setup building for a shared library system?
Actually I just noticed that RO_SHAREDLIBS (which defines if you want a
shared libs enabled build or not) was hardwired to "yes" in
$GCCSDK_INSTALL_ENV/ro-config. That's wrong as this is a user (builder)
option and I've just commited a fix for this. This also means now that
Autobuilder builds are by default 'static' now.
Should programs for the end-user be built static?
Yes, I would prefer to have static AIF binaries released for now using the
current GCC4 infrastructure. And this until we convinced ourselves that
our shared libraries are working for complex programs. I believe Peter
got rather far with shared libs in his Firefox build but I'm not sure what
what the remaining issues are.
The question is pretty complex, but may yet have solutions, and I'm not
sure if I immediately agree with the change that John has just made. At
the same time, this issue has been compounded a bit by both him and
myself not being able to do any meaningful work on GCCSDK for some
months.
Anyway, for the autobuilder, e1f2aif is always run on binaries, but
of course that will tend to fail for non-trivial programs, since
programs will likely be dynamically linked if the build of dependencies
is dynamic - even though we also try to build the static library in
this case.
This is worse in the case of GTK and friends; if you try to generate
a static binary against libraries with both static and dynamic version,
you end up needing stuff in -ldl for static binaries.
The end result is that if you want to switch between the two types of
build, you often have to rebuild everything, which is a bit tedious.
For Firefox, I've kind of been waiting for a full release of GCC 4,
along with some packaged libraries, since it can't really be done
piecemeal. There are still a couple of issues with the shared
library version of Firefox (try searching csa.p), but it's not
obvious that those would directly affect other programs which
are dynamically linked.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
