Re: only static libraries created
[EMAIL PROTECTED] wrote: Hi, I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? The problem is that the library consists of some sub-packages (sub-directories) that are linked together before the whole library is created. For those sub- packages just static library files (.a) are created, I suppose there should be .dlls that can be linked to the toplevel library, to avoid warnings like: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. ^ How did you do that? -- guido *** 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. As a consequence, no .dll is created in the toplevel directory, that should include all the sub-packages. I use the -no-undefined LDFLAG (set as an environment variable for configure), is this still necessary for libtool-1.5? I also tried to add the macro AC_PROG_LIBTOOL_WIN32_DLL to Makefile.in, but this made no difference, i read somewhere on the net that this is not required anymore. thanks, Bernhard libtool-1.5 autoconf-2.57 automake-1.7.6 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- -- guido http://google.de/search?q=guidod GCS/E/S/P C++/$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
You may want to ask at mingw.org for specifics. If all dependencies are resolved then a dll should be there as $subdir/.libs/*.dll - check the content of the .la files in $subdir/*.la whether it has been configured correctly to create dynalibs (it's a text file). Then do the next step. [EMAIL PROTECTED] wrote: Hi, I want to compile gtkhtml2 (libgtkhtml) for windows, I use MinGW (gcc-3.2.3) and cygwin. My problem is that only static libraries are created, no .dlls. What could be the reason for this? The problem is that the library consists of some sub-packages (sub-directories) that are linked together before the whole library is created. For those sub- packages just static library files (.a) are created, I suppose there should be .dlls that can be linked to the toplevel library, to avoid warnings like: *** Warning: This system can not link to static lib archive c:/libpath/lib/libfoo.la. *** 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. As a consequence, no .dll is created in the toplevel directory, that should include all the sub-packages. I use the -no-undefined LDFLAG (set as an environment variable for configure), is this still necessary for libtool-1.5? I also tried to add the macro AC_PROG_LIBTOOL_WIN32_DLL to Makefile.in, but this made no difference, i read somewhere on the net that this is not required anymore. thanks, Bernhard libtool-1.5 autoconf-2.57 automake-1.7.6 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- -- guido http://google.de/search?q=guidod GCS/E/S/P C++/$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote: > > I want to compile gtkhtml2 (libgtkhtml) for windows, > I use MinGW (gcc-3.2.3) and cygwin. > > My problem is that only static libraries are created, > no .dlls. What could be the reason for this? Alas, it is necessory for all libraries that your DLL depends on to also be built as DLLs. > The problem is that the library consists of some > sub-packages (sub-directories) that are linked together > before the whole library is created. For those sub- > packages just static library files (.a) are created, > I suppose there should be .dlls that can be linked to > the toplevel library, to avoid warnings like: > > *** Warning: This system can not link to static lib archive > c:/libpath/lib/libfoo.la. > *** 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. > > As a consequence, no .dll is created in the toplevel > directory, that should include all the sub-packages. > > I use the -no-undefined LDFLAG (set as an environment > variable for configure), is this still necessary for > libtool-1.5? I also tried to add the macro > AC_PROG_LIBTOOL_WIN32_DLL to Makefile.in, but this > made no difference, i read somewhere on the net that > this is not required anymore. Since Windows DLLs do not allow undefined symbols, a requirement to build a DLL using libtool is to include the -no-undefined option, otherwise a static library will be built. Libtool 1.5 is much better at enforcing these rules than former versions of libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Guido Draheim wrote: > [EMAIL PROTECTED] wrote: > > *** Warning: This system can not link to static lib archive > > c:/libpath/lib/libfoo.la. >^ > > How did you do that? -- guido Since libtool on cygwin usually generates unix/cygwin-style paths (starting with /cygdrive/[...]), MinGW-gcc was not able to link some of the newly generated libraries (.a). That's why I modified the respective .la file of the library and set 'libdir' to the correct path of the library file (and installed to 'yes'). Otherwise I was not able to proceed. Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Guido Draheim wrote: > If all > dependencies are resolved then a dll should be there > as $subdir/.libs/*.dll - check the content of the .la > files in $subdir/*.la whether it has been configured > correctly to create dynalibs (it's a text file). Then > do the next step. hmm, what can I check in the .la files? Whether there is a name set for 'library_names'? thanks, Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bernhard Rumpler wrote: > On Thu, 25 Sep 2003, Guido Draheim wrote: > > [EMAIL PROTECTED] wrote: > > > *** Warning: This system can not link to static lib archive > > > c:/libpath/lib/libfoo.la. > >^ > > How did you do that? -- guido > > Since libtool on cygwin usually generates unix/cygwin-style paths > (starting with /cygdrive/[...]), MinGW-gcc was not able to link some of > the newly generated libraries (.a). That's why I modified the respective > .la file of the library and set 'libdir' to the correct path of the > library file (and installed to 'yes'). Otherwise I was not able to > proceed. Cygwin and MinGW tools differ significantly in that Cygwin tools deal with Unix paths while MinGW tools accept Windows paths. The easiest way to deal with MinGW is to use the MSYS shell which provides a limited Cygwin-like shell capable of supporting configure, make, and libtool, while automatically transforming Unix paths into the Windows paths that the tools require. While Cygwin does provide a compiler mode in which it may compile programs which use the MinGW library, there may be some problems with crossing over between the two environments. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bob Friesenhahn wrote: > On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote: > > I want to compile gtkhtml2 (libgtkhtml) for windows, > > I use MinGW (gcc-3.2.3) and cygwin. > > > > My problem is that only static libraries are created, > > no .dlls. What could be the reason for this? > > Alas, it is necessory for all libraries that your DLL depends on to > also be built as DLLs. This prerequisite is fulfilled for all dependencies. But since no .dlls are created in the subdirectories, no .dll is built for the whole library. When I try to link static libraries, then a warning "Linking the shared library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is not portable!" is displayed. What does "not portable" mean in this context? Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
Bob Friesenhahn writes: > While Cygwin does provide a compiler mode in which it may compile > programs which use the MinGW library, there may be some problems with > crossing over between the two environments. This might be obvious to many, but anyway: I have found that to ensure a mixture of Cygwin-based tools (for instance shell scripts that run under a Cygwin shell, or Cygwin Perl scripts) and native (mingw) tools interoperate reliably one needs to make sure that the same paths are valid (and point to the same files) in both. This isn't that hard. If you have sources in for instance e:\some\place, and do your builds there, make sure that e:\some is mounted in Cygwin as /some. And if you do "make installs", and/or use installed libraries and headers for some package, make sure that the same holds for the installation location, and that it is on the same drive. (For instance if you install to, or use stuff installed in, e:\another\place, mount e:\another as /another.) --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bob Friesenhahn wrote: > The easiest way to deal with MinGW is to use the MSYS shell which > provides a limited Cygwin-like shell capable of supporting configure, > make, and libtool, while automatically transforming Unix paths into > the Windows paths that the tools require. Yes, but there are no binaries of current versions of various developer tools available for MSYS, that's one problem. I have not yet tried to build gtk-related stuff with MSYS, since some people who do that (including the maintainer of the windows port) use MinGW and cygwin for that, and recommend this solution. It supposedly "causes less problems". I don't know details, but I'll have to find out, if I dont't get dlls built with cygwin bash and cygwin libtool. I still hope I can do it with cygwin, there can only be a few little things I'm missing to do... > While Cygwin does provide a compiler mode in which it may compile > programs which use the MinGW library, there may be some problems with > crossing over between the two environments. yes, but there, too, seem to exist problems with mixing up cygwin and mingw libraries. Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On Thu, 25 Sep 2003, Bernhard Rumpler wrote: > On Thu, 25 Sep 2003, Bob Friesenhahn wrote: > > On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote: > > > I want to compile gtkhtml2 (libgtkhtml) for windows, > > > I use MinGW (gcc-3.2.3) and cygwin. > > > > > > My problem is that only static libraries are created, > > > no .dlls. What could be the reason for this? > > > > Alas, it is necessory for all libraries that your DLL depends on to > > also be built as DLLs. > > This prerequisite is fulfilled for all dependencies. But since no .dlls > are created in the subdirectories, no .dll is built for the whole library. Make sure that all of the DLLs are in your executable search path or may be found in a directory "../bin" offset from where the .a and .la files are located. If libtool can't find the actual DLL then it will assume that the .a library is an implementation library and not an interface library for a DLL. > When I try to link static libraries, then a warning "Linking the shared > library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is > not portable!" is displayed. What does "not portable" mean in this > context? I suspect that this complaint is because the library doesn't have versioning information as part of its name. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
Bob Friesenhahn wrote: On Thu, 25 Sep 2003, Bernhard Rumpler wrote: When I try to link static libraries, then a warning "Linking the shared library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is not portable!" is displayed. What does "not portable" mean in this context? I suspect that this complaint is because the library doesn't have versioning information as part of its name. This complaint is because libhtmllayouthtml.la was linked with the -module flag to libtool, which means it is meant to be a dlopenable module, and on some platforms (Mac OS X/darwin NetBSD/a.out) may not be used as input to the linker. If libhtmllayouthtml.la was not linked with the -module flag, it is a bug. Thanks, Peter -- * Peter O'Gorman - http://www.pogma.com/ * ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
Tor Lillqvist wrote: I have found that to ensure a mixture of Cygwin-based tools (for instance shell scripts that run under a Cygwin shell, or Cygwin Perl scripts) and native (mingw) tools interoperate reliably one needs to make sure that the same paths are valid (and point to the same files) in both. This isn't that hard. If you have sources in for instance e:\some\place, and do your builds there, make sure that e:\some is mounted in Cygwin as /some. And if you do "make installs", and/or use installed libraries and headers for some package, make sure that the same holds for the installation location, and that it is on the same drive. (For instance if you install to, or use stuff installed in, e:\another\place, mount e:\another as /another.) which kind of problems can be avoided with this setup? One problem for me is that (even if I mount c: as /c) libtool always creates unix-style paths (e.g., /c/somewhere/.libs/libfoo.la) but mingw-gcc does not understand that. The problem is that this always occurs, when a library is built and the source code is organized in a number of subdirectories, and intermediate .a and .la files are generated for the subdirectories, which are then used to build up the .dll (or some other .a files) in higher level directories. @ Tor: This probem also occurs for some files, if I build glib-2.2.3, how do you avoid this when you build glib? Does your setup with mounting directories have any influence on this? For now I always have to modify the respective .la files of the .a files in the subdirectories, to be able to link them. For this I set library_name (?? is this OK??) to the name of the .a file, installed=yes and the libdir to the respective .libs directory containing the .a file. Not a very good solution, and I'm also quite unsure, if this can cause problems. thanks for any hints, Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: only static libraries created
On 26.09.2003 02:44:28 [EMAIL PROTECTED] wrote: >Bob Friesenhahn wrote: >> On Thu, 25 Sep 2003, Bernhard Rumpler wrote: >>>When I try to link static libraries, then a warning "Linking the shared >>>library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is >>>not portable!" is displayed. What does "not portable" mean in this >>>context? >> >> I suspect that this complaint is because the library doesn't have >> versioning information as part of its name. > >This complaint is because libhtmllayouthtml.la was linked with the >-module flag to libtool, which means it is meant to be a dlopenable >module, and on some platforms (Mac OS X/darwin NetBSD/a.out) may not be >used as input to the linker. > >If libhtmllayouthtml.la was not linked with the -module flag, it is a bug. no, it is not linked with the -module flag. Could the problem be caused by my modifications of the respective ".la"-file, as described in another message of this thread: Bernhard Rumpler wrote: >For now I always have to modify the respective .la files of the >.a files in the subdirectories, to be able to link them. For this >I set library_name (?? is this OK??) to the name of the .a file, >installed=yes and the libdir to the respective .libs directory >containing the .a file. Not a very good solution, and I'm also quite >unsure, if this can cause problems. thanks, Bernhard ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
