Casper.Dik at sun.com wrote:
>
> >The problem is that libast has headers which are meant to "replace" the
> >normal system headers, e.g. /usr/include/ast/stdio.h which is included
> >as <stdio.h> in the various AST sources. Since $(CPPFLAGS.master)
> >includes stuff "-I$(ROOT)/usr/include" and normally comes before any
> >other -I options from the Makefile* it breaks this. Using
> >$(CPPFLAGS.master) is tricky, too - it MUST come as the last element but
> >future changes in -D may then cause silent breakage in the AST sources
> >because the last -D specified overrides previous -D options so I prefer
> >the current way to expliclity list each single flag. Otherwise it may
> >end-up in a horrible pain to figure out a problem which is simply caused
> >by a tiny change in the flags used in $(CPPFLAGS.master).
> >What should I do here now - leave it as it implemented currently or try
> >to "squish" $(CPPFLAGS.master) somewhere into the chain in the hope that
> >this won't bite back in the future... ?
>
> This seems wrong; personally I think we should rip out any replacement
> for system libraries; such duplication leads to more code which needs
> to be maintained. This includes replacements for <stdio.h>.
See below...
> (The problem is even bigger if these are indeed shipped as part of
> the ksh libraries; having multiple implementations visible to processes
> is bad; note that re-exporting symbols like fopen() would be blatantly
> illegal in C and therefor also in Solaris; our libraries will malfunction
> when they find a different stdio library)
Erm, I said this already a while ago: libast is an OS abstraction layer
similar to NSPR ("Netscape Portable Runtime", used in Mozilla, Firefox,
Thunderbird and almost every other Netscape product).
Part of libast is an I/O library called "sfio". "sfio" is different in
the provided API and does not even intend to be stdio-compatible in any
way (the different implementation and API results in far superiour
performace compared to the normal stdio implementation, making this an
item where we should think about moving performance-critical
applications which heavily depend on I/O throughput over from stdio to
sfio...).
On top of "sfio" a stdio-compatibility layer was added (which doesn't
even attempt to be 100% compatible to the stdio API but is usually be
"close enougth" for most small applications (including "perl")) which
include some wrappers to emulate the stdio API (applications can archive
this simply via including /usr/include/ast/stdio.h instead of
/usr/include/stdio.h).
Both stdio versions can be used at the same time in the same application
(assuming they are in different source files) without problems (it's
explicitly designed that way).
And if someone has problems with that please complain about NSPR first -
they do exactly the same for the same reasons. And AFAIK mysql, Apache,
JAVA, Gnome and other stuff shipped with Solaris include such
"portabilty layers", too.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
