🚀 go-pugleaf

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.

>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.  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.


If anyone has problems with these in the meantime please contact me or
<cw_support@metrowerks.com> and we'll try to get something that fixes the
problems for you.

Ron

-- 
 "...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm

Metrowerks, "Software Starts Here" - Ron Liechty - MWRon@metrowerks.com