🚀 go-pugleaf

In article <mwron-0211001305180001@c243286-a.bcreek1.mi.home.com>,
MWRon <mwron@metrowerks.com> wrote:

> In article <021120000814585412%hawkfish@spam.invalid>, Richard Wesley
> <hawkfish@spam.invalid> wrote:
> 
> >Here is the crux of the problem.
> >
> >MW considers the MSL headers to be MSL headers.  I consider them to be
> >standard C headers.
> 
> There are standard headers in MSL and there are non standard headers in
> MSL  we consider the standard headers (both ANSI/ISO and POSIX) as public
> standard headers.  
> 
> >  MW gave them the names of the standard headers but
> >implemented them in such a way as they can only be used with MSL.  This
> >may be legal, but it is sure a pain in the neck for porting. 
> 
> The problem is that some legacy libraries now no longer link with our
> headers since the functions are inlined and we failed to take this into
> account.

Exactly.

> >For what it does, I can see it is better, but I think that actually
> >exporting the symbols would be even better.
> 
> We are working on a fix for this and will release it as an update.  

Great!

> There
> are several work arounds.  Rebuild the third party libraries so they use
> the CW 6 headers  (not ideal since then they may not support older
> versions)  write your own set of POSIX using the MSL sources  (not ideal
> for anything other than one or two functions)  or for Metrowerks to add
> some additional code so that both the _xxxx and the xxxx versions of the
> POSIX functions are available using a declexport statement.   This is the
> ideal solution but does involve rebuilding the entire MSL Libraries, so it
> would probably not be something we'd do until there was another major
> update being released.

We look forward to it.

-- 
Richard Wesley           Electric Fish, Inc.    hawkfish@NeOlSePcAtMricfish.com

"Before we begin our banquet, I would like to say a few words.  And here they
 are:  Nitwit! Blubber! Oddment! Tweak!" - "Harry Potter & Philospher's Stone"