| www.delorie.com/archives/browse.cgi | search |
Chris Faylor <cgf AT cygnus DOT com> writes:
>
> So, what do you think? Should we just provide a dummy libc.a and
> libm.a? I think that it will be clearer what's going on if there is a
> symbolic link, won't it?
>
> Otherwise, we'll be getting messages like:
>
> "My libc.a is only 14 bytes. I think that's why I'm getting syntax errors
> in my source file."
I honestly don't know what's better. Users are used to seeing Unix systems
symlink libc and libm, so it won't be surprise to anyone. Dummy ones have
the added advantage that they'll work "natively" (symlinks are not visible
outside the emulation of course).
My two second response (have to run) --
pro:
- using ld (as opposed to gcc) will work as expected. Lots of configure
script will run `ld ... -lc' etc. I consider it bad practice in
general, but it's out there. This currently doesn't work either.
con:
- non-cygwin apps can't look inside libc.a or libm.a. This may or may
not be an issue, but something to think about.
For a few 100k extra disk space, we could just hard link it (which will
eventually not copy when Cygwin supports native hard linking).
Principle of least surprise should be our goal.
Regards,
Mumit
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |