This is the mail archive of the cygwin-patches 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: The Return of Revenge of Son of the Speclib Strikes Back :)


Christopher Faylor wrote:
> On Sat, Apr 18, 2009 at 02:53:37PM +0100, Dave Korn wrote:

>> The new speclibs libraries work great, but there's one piece of
>> unanticipated fallout: the libtool func_win32_libid() tests can no
>> longer identify them as import libraries.  Which is fair enough, since
>> they aren't, they are now indirect references to import libraries; but
>> we want it to treat them the same anyway.
> 
> I can guess why that is, but it would be nice if you didn't jump right
> to a solution and provided more details.

  Sorry, thought that might be enough.  For the sake of the archives:  We want
to treat these as import libraries, because otherwise libtool says:

*** Warning: linker path does not have real file for library -ldl.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libdl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libdl.a

  We do in fact have a shared version of the library, since anything in a
speclib library refers to a function in the Cygwin DLL.  But because the stubs
in the speclib libraries only indirect to the actual import symbol, libtool
doesn't realise this; the library itself doesn't import anything, and
libtool's test is based on grepping the output of nm to look for a symbol with
" I " in the type field.

>> As usual, I don't speak perl good,
> 
> So, please don't bother sending perl patches.  I can get enough out of
> the description of what is wrong and what your possible solution might
> be to figure out what needs to be done without seeing your
> proof-of-concept.

  Well, it's either harmless extra information, or it will actually clarify
any ambiguities that might exist in my description, so it can't hurt and may
in the event that I mis-speak actually do some good.  There's certainly not
supposed to be any obligation on you to debug it or anything.

> I checked something in which adds a dummy object custom-tailored to the
> each library.
> 
> Thanks for the report.

  Thanks for the fix!

    cheers,
      DaveK


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