This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: libcygwin.a as a symbolic link to lib{c,m}.a -- need insight


Chris Faylor <cgf@cygnus.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]