This is the mail archive of the cygwin-developers@cygwin.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]
Other format: [Raw text]

Re: 1.5.0 - showstopper?


Corinna said:
> I'm curious, does that still make sense now?  Should libcygwin.a be added
> to that list or is the problem ultimativly fixed by adding the appropriate
> symbols to libcygwin.a?  Somehow I'm missing the conclusion in this
> discussion.

cgf's fix to newsym and rmsym solved this problem. I still believe that
libcygwin.a should be in ld's exclude list, but it's not actually
NECESSARY to do that, given cgf's fix.

Max said:
> There is at least one other problem that I think would be avoided if
> libcygwin was in the excludes: currently, if you build a dll which uses
> getopt, getopt will be reexported from the dll. Now try to link to the dll -
> the linker complains because getopt is available in both the dll and
> libcygwin.a.

Yes, but in that case you're simply pushing the problem farther down the
food chain.  What if we did this, and you try to build libfoo and libbar
(which both export getopt or some other identical symbol).  Then, you
link baz.exe against both libfoo and libbar....boom!

In cygwin, a symbol that appears in two import libraries causes a
linktime conflict.  On most unixes, I think, the link will succeed and
baz(.exe) will grab the symbol only from the first library on the link
line, not from the second and certainly not from both.

Even on cygwin, I believe that if you have an identical symbol in two
STATIC libs, only the first one is used and there is no error (not sure
about this; it's easy enough to test).

The problem occurs when two *import* libs both present the same symbol. 
Is this a bug in ld?  Is it a design issue, or the price of running on
top of MSWin?  I dunno...

See note, below.

> But I think is safe to say this is not a showstopper, since it has been this
> way for quite some time.

Agreed.

note: from /usr/doc/Cygwin/gettext-*.README, in the section which
discusses the 0.11.2 release...

"these libraries" == libgettextsrc and libgettextlib, two internal
libraries (shared), which are used solely by the gettext executable
utilities

  3) pull out the getopt functions from these libraries, 
     and put them into their own libgetopt.a convenience
     library.   This is because cygwin itself provides the
     getopt functions, and 
       (a) if a function is listed in TWO import libs, ld
           reports an error.  /usr/lib/libcygwin.a and
           libgettextlib.dll.a would both contain the getopt
           symbols, so we remove them.
       (b) BUT, we CAN'T use the version provided by cygwin!!
           Cygwin's version hardcodes the POSIXLY_CORRECT variable,
           which means we cannot reorder options and arguments --
           but gettext's tests rely on reordering.
       (c) We CAN override functions that might be imported from
           a dll via an import lib by using an explicit STATIC
           lib.  So, 
     getopt.c getopt.h getopt1.c  all go into the convenience lib
     libgetopt.la instead of the regular lib libgettextlib.la.
     (Recall that convenience libs are always built statically).
          Add libgetopt.la as a dependence for all exe's.
--
  Charles Wilson
  cygwin at removespam cwilson dot fastmail dot fm


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