| delorie.com/archives/browse.cgi | search |
"Gerrit P. Haase" wrote: > I dislike this, as long as they use libtool we should try to use it. It wasn't my first choice either. I tried to find a "libtool --mode=link" command line that would take the specified *.lo files and produce a .dll, but I could not find a way. It just seemed silly to link to .a and .la and then basically relink the whole thing over again (having to respecify all the dependent libs) in that awful mkdll.sh hack. If you know of how to tell libtool to make a .dll then I'm all ears. The other problem with leaving them as .a / .la is that they must be dynamically loaded with dlopen(). I tried using the produced .a files but got an error about "not a valid format" or something because the underlying Windows function expected a .dll. > Are the fixes in the config.m4 file really needed? Which of our > libraries are not available as static archive so they are not found? Hmm, looking at it again I see that you may be right. I was having problems with it not finding libxml2 (which on cygwin is just /usr/lib/libxml2.dll.a and .la) but it appears that all the others are extraneous. They must have been remnants left over of various failed attempts at getting it to go, before everything was working. > I have a fix (cygwin-special) for the DBA / BDB4 issue. > I will try to figure out how to get all the shared modules with the > built-in methods (no automake & libtool). What do you mean "no automake and libtool"? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |