In message <[EMAIL PROTECTED]>
alan buckley <[EMAIL PROTECTED]> wrote:
> I thought there are several options for an application
>
> ELF using shared libraries
> ELF using static libraries
> AIF
I don't think the last two are meaningfully different right now.
Certainly not for users, and nor for any functionality we use. That
might change in future with certain debug tools. In any case, the AIF
conversion happens only during packaging, so there's nothing stopping
you getting the static ELF if you're building it yourself.
> I also thought that ELF libraries are built as static and shared so that
> the linking program could decide what to use.
>
> Where am I mistaken?
I think in practice, from my experiments that also building dynamic
libraries can end up breaking static builds. This is because -ldl ends
up in various places which isn't real helpful for static builds.
Perhaps this was some artifact of my build, which I might have already
resolved, but I'd take care.
> How about AB_SHARED that means create and ELF program
> or a shared as well as static version of the library?
Perhaps it should do simply what the build default is. In general, this
is usually the above (but sometimes only dynamic). That is partly why I
had the odd naming for the variable. I think that'll be agreeable for
all.
> This is why I proposed the "wrong" defaults. So that I could just
> make one minor change for my testing while it continued to build
> static libraries and aif files for everyone else. The variable would
> then be in place for when the switch over to ELF as default
> happened.
I recommend that for such experiments, you might be best with a whole
new 'env' dir. This is simple to arrange with build-setvars, and that
can add a suffix for the last-* files in the autobuilder to keep track
of different builds.
--
Peter Naulls - [EMAIL PROTECTED] | http://www.chocky.org/
----------------------------------------------------------------------------
RISC OS Community Wiki - add your own content | http://www.riscos.info/
_______________________________________________
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
