Re: About win32 impgen.c patch
Robert, Naofumi,
One of the things I am curious about is whether or not impgen.c is
going to be used very often in the future. I had been of the notion
that the latest set of patches more or less did away with the use of
that particular piece of code, although the code for impgen.c itself
has not been removed.
From what I understand, the newer gcc (and/or gnu ld) on win32 uses
an auto import feature, and the old way of importing symbols (via
compiling impgen.c) is no longer needed, although there was some
platform that still uses the older method (pc32 or something like
that; right under mingw in the C compiler case/select).
I personally would like to see impgen.c done away with altogether
eventually if possible, because it seems out of place - compiling a
bit of code to pull symbols out of a library. When cross-compiling,
this makes the job a little more difficult (difficult in the sense
that one must be a little more knowledgeable about what is happening
during the build [read: set HOST_CC to the native {build} compiler]).
If Bob is out there, Bob, when you build IM on MSYS using your
latest set of mingw-specific patches, is it using impgen.c any longer?
Regards, Elizabeth
Robert Boehne [EMAIL PROTECTED] writes:
Naofumi,
Your patch has not been approved, but it hasn't been
rejected either. If you could briefly explain what
the problem is and how your patch fixes it, I'd be
glad to approve it. I'm reluctant to commit patches
that I don't understand, and I'm not familiar with the
reason you'd need to quote the string if it has the .
character in it.
Thanks,
Robert
Naofumi Yasufuku wrote:
Hi,
Can anybody tell me whether this impgen.c patch was approved?
http://mail.gnu.org/pipermail/libtool-patches/2002-August/002073.html
In gtkmm2 for win32, impgen cannot generate the correct import library
which contains a special symbol name includes '.' character.
This patch fixes the problem.
Regards,
--Naofumi
___
Libtool-patches mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool-patches
___
Libtool-patches mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool-patches
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Earnie Boyd [EMAIL PROTECTED] writes: I'm fine with it and will support the change [of the maximum command line length] to a constant. Should that constant be adjusted based on w9x vs NT? I would not think so; rather, it seems to me that a 8192 character command line maximum will work for most anyone. Do we have the option of switching between NT and w9x? Elizabeth ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Earnie Boyd [EMAIL PROTECTED] writes: I've seen some looong command lines, not that I've stopped to count the characters. The 8192 may not be enough for some packages. Is there a mehtod to use that doesn't check the command line length or is the point of the limit to break the command line into parts? I do not know why it is used. It sets the variable `max_cmd_len' is all I can tell that it does in libtool.m4. with Cygwin and MSYS, unmae tacks it on the system name. Ok. Elizabeth ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Bob Friesenhahn [EMAIL PROTECTED] writes:
The exact same error message is reported without -shared.
From what I can tell, during configure, there is a check for any
object files that are included in a C++ link. This object file is then
later used to build the shared archive.
If you look at libtool.m4, wherever this is (reading it off the web):
cygwin*)
# _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_AC_TAGVAR(always_export_symbols, $1)=no
if $LD --help 21 | egrep 'auto-import' /dev/null; then
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname
${wl}--image-base=0x1000 ${wl}--out-implib,$lib'
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname
${wl}-retain-symbols-file $wl$export_symbols ${wl}--out-implib,$lib'
else
_LT_AC_TAGVAR(ld_shlibs, $1)=no
fi
;;
mingw* | pw32*)
# FIXME: insert proper C++ library support
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
You see that, for mingw, it needs to be fixed and I propose that
someone *TEST* taking the cygwin implementation and moving down to
where mingw is, *and* removing the $predep_objects, like this:
mingw* )
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_AC_TAGVAR(always_export_symbols, $1)=no
if $LD --help 21 | egrep 'auto-import' /dev/null; then
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $libobjs $deplibs
$postdep_objects $compiler_flags -o $output_objdir/$soname
${wl}--image-base=0x1000 ${wl}--out-implib,$lib'
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib $libobjs $deplibs
$postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}-retain-symbols-file
$wl$export_symbols ${wl}--out-implib,$lib'
else
_LT_AC_TAGVAR(ld_shlibs, $1)=no
fi
;;
pw32* )
# FIXME: insert proper C++ library support
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
What is the conventional wisdom on this?
Elizabeth
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
test to see if the mailing list is working
test. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Bob, all,
This patch allowed libMagick++ to compile on my machine.
The one thing that concerns me is the name of the import library is
hard-coded ${lib}.a, which is okay in that the import library looks
like qqq.dll.a but Max has something going about putting DLLs with
the executables and the libraries in the library directory during
install. Is this going to help or hinder Max's work?
Elizabeth
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.266
diff -u -p -3 -r1.266 libtool.m4
--- libtool.m4 11 Oct 2002 15:52:08 - 1.266
+++ libtool.m4 11 Oct 2002 20:46:18 -
@@ -620,7 +620,14 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [d
lt_cv_sys_max_cmd_len=-1;
;;
- *)
+
+ mingw*)
+# On msys 1.0 and win98, the maximum length was something like
+# 200,000 and took around 45 minutes to get there... ouch!
+lt_cv_sys_max_cmd_len=32768;
+;;
+
+ *)
# If test is not a shell built-in, we'll probably end up computing a
# maximum length that is only half of the actual maximum length, but
# we can't tell.
@@ -2624,12 +2631,25 @@ case $host_os in
else
_LT_AC_TAGVAR(ld_shlibs, $1)=no
fi
-;;
+ ;;
- mingw* | pw32*)
-# FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
-;;
+ mingw* )
+_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+_LT_AC_TAGVAR(always_export_symbols, $1)=no
+
+if $LD --help 21 | egrep 'auto-import' /dev/null; then
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs $deplibs
+$compiler_flags -o $output_objdir/$soname ${wl}--out-implib,${lib}.a'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC '$lt_cv_cc_dll_switch' $libobjs
+$deplibs $compiler_flags -o $output_objdir/$soname ${wl}-retain-symbols-file
+$wl$export_symbols ${wl}--out-implib,${lib}.a'
+else
+ _LT_AC_TAGVAR(ld_shlibs, $1)=no
+fi
+ ;;
+
+
+ pw32* )
+ # FIXME: insert proper C++ library support
+_LT_AC_TAGVAR(ld_shlibs, $1)=no
+ ;;
dgux*)
case $cc_basename in
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Max Bowsher [EMAIL PROTECTED] writes:
Don't worry about me! I think we are working towards broadly similar goals -
it shouldn't be much effort for me to merge the changes you are making into
my stuff.
What I'm wondering is of there is a better variable to use with the
import library, as opposed to ${lib}.a ?
+ mingw*)
+# On msys 1.0 and win98, the maximum length was something like
+# 200,000 and took around 45 minutes to get there... ouch!
+lt_cv_sys_max_cmd_len=32768;
+;;
One of my patches merges a change from Cygwin for this. Caution though. I
read there that the max length for NT systems is only 8192 - so this patch
needs adjusting to not break libtool on NT.
I'd very much like to add this or something similar (8192) to the
distribution because, on my machine at least, it took about 45
minutes.
What is the MSYS-team's view on this?
Thanks Max,
Elizabeth
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Bob Friesenhahn [EMAIL PROTECTED] writes: CVS libtool fails to link C++ DLLs under MinGW, but succeeds under Cygwin. I have looked at the .la files, and everything appears to be in order there, so the problem seems to be during the C++ DLL link phase. The MinGW environment is the base MinGW release, with Windows API updates applied. The behavior of libtool when linking under Cygwin and MinGW is shown below (lines wrapped for clarity). Please let me know if you spot a reason for the failure. Hi Bob, For some reason I am temporarily unable to pull down a copy of the current libtool via CVS (the latest change in the ChangeLog is from 09/2001). May I have a copy of your config.log? Thank you, Elizabeth ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Bob Friesenhahn [EMAIL PROTECTED] writes: Ideas? g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o .libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o .libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o .libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o .libs/TypeMetric.o -L/usr/local/lib ../../magick/.libs/libMagick-5.dll -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib -L/mingw/lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. -L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt -o .libs/libMagick++-5.dll What happens if you run the above line by itself without the -shared switch? Elizabeth ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Bob Friesenhahn [EMAIL PROTECTED] writes: g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o .libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o .libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o .libs/Montage.o .libs/Options.o .libs/Pixels.o .libs/STL.o .libs/Thread.o .libs/TypeMetric.o -L/usr/local/lib ../../magick/.libs/libMagick-5.dll -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib -L/mingw/lib/gcc-lib/mingw32/2.95.3-6 -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../.. -L/mingw/lib/gcc-lib/mingw32/2.95.3-6/../../.. -lstdc++ -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt -o .libs/libMagick++-5.dll What about removing the first object file, the: c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o part? The reason is that the multiple definitions were coming from within that particular object file - what happens without it? Elizabeth ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?
Earnie Boyd [EMAIL PROTECTED] writes: Ok, submit a proper patch against the CVS source to [EMAIL PROTECTED] for proper credit for the fix. Okay, I am satisfied with this and submit this patch for peer review. SYNOPSIS: Adds a linker flag check for -shared before those that are all ready defined when building a win32 dll (using the AC_LIBTOOL_WIN32_DLL in configure.ac) for a mingw* host. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/libtool.m4,v retrieving revision 1.264 diff -r1.264 libtool.m4 510c510 # require -mdll --- # require -mdll (and still newer ones would rather have -shared) 512c512 CFLAGS=$CFLAGS -mdll --- CFLAGS=$CFLAGS -shared 514c514,517 [AC_TRY_LINK([], [], [lt_cv_cc_dll_switch=-mdll],[lt_cv_cc_dll_switch=-dll])]) --- [AC_TRY_LINK([], [], [lt_cv_cc_dll_switch=-shared], [ CFLAGS=$SAVE_CFLAGS -mdll AC_TRY_LINK([], [], [lt_cv_cc_dll_switch=-mdll],[lt_cv_cc_dll_switch=-dll])])]) Regards, Elizabeth ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?
Earnie Boyd [EMAIL PROTECTED] writes:
On a related note, I have been having to add a main function to the
DLL's like so:
#if defined(__MINGW32__) defined(DLL_EXPORT)
int
main(int argc, char* argv[])
{
return 0;
}
#endif
You shouldn't do this. I posted on the libtool list a
mingwlibsample.tar.gz under the heading of Simple dll and static
library creation for MinGW dated 9/19/2002.
http://www.soggytrousers.net/repository/mingwlibsample.tar.gz
If I do not add this, it does not build the DLL. I'm concerned about
the export of this function, however - if more than one DLL uses this
method, could there be some kind of conflict and/or is there a better
way to deal with this?
The -shared switch is required to build the dll.
If anyone is interested in this, libtool made the dll fine without the
main function mentioned above by adding -shared after the $CC:
--BEGIN--
# Commands used to build and install a shared archive.
archive_cmds=
archive_expsym_cmds=if test \\\x\\\`sed 1q \$export_symbols\\\`\\\ = xEXPORTS; then
cp \$export_symbols \$output_objdir/\$soname-def;
else
echo EXPORTS \$output_objdir/\$soname-def;
_lt_hint=1;
cat \$export_symbols | while read symbol; do
set dummy \\\$symbol;
case \\\$# in
2) echo \\\ \\\$2 @ \\\$_lt_hint ; \\\
\$output_objdir/\$soname-def;;
4) echo \\\ \\\$2 \\\$3 \\\$4 ; \\\ \$output_objdir/\$soname-def;
_lt_hint=\\\`expr \\\$_lt_hint - 1\\\`;;
*) echo \\\ \\\$2 @ \\\$_lt_hint \\\$3 ; \\\
\$output_objdir/\$soname-def;;
esac;
_lt_hint=\\\`expr 1 + \\\$_lt_hint\\\`;
done;
fi~
\$CC -shared -Wl,--base-file,\$output_objdir/\$soname-base
-Wl,-e,_DllMainCRTStartup@12 -o \$output_objdir/\$soname \$libobjs \$deplibs
\$compiler_flags~
\$DLLTOOL --as=\$AS --dllname \$soname --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12
--def \$output_objdir/\$soname-def --base-file \$output_objdir/\$soname-base
--output-exp \$output_objdir/\$soname-exp~
\$CC -shared -Wl,--base-file,\$output_objdir/\$soname-base
\$output_objdir/\$soname-exp -Wl,-e,_DllMainCRTStartup@12 -o \$output_objdir/\$soname
\$libobjs \$deplibs \$compiler_flags~
\$DLLTOOL --as=\$AS --dllname \$soname --exclude-symbols
DllMain@12,_cygwin_dll_entry@12,_cygwin_noncygwin_dll_entry@12,DllMainCRTStartup@12,DllEntryPoint@12
--def \$output_objdir/\$soname-def --base-file \$output_objdir/\$soname-base
--output-exp \$output_objdir/\$soname-exp --output-lib \$output_objdir/\$libname.dll.a~
\$CC -shared \$output_objdir/\$soname-exp -Wl,-e,_DllMainCRTStartup@12 -o
\$output_objdir/\$soname \$libobjs \$deplibs \$compiler_flags
postinstall_cmds=
postuninstall_cmds=
--END--
Note the addition of -shared after the \$CC. Similar lines may be
found in libtool.m4 v. 1.264 at 4700, 4702 and 4704.
Elizabeth
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?
This is just a simple report-in about the errors I mentioned having
yesterday or the day before. The latest CVS libtool did not have any
trouble and made the DLL fine.
I'd also like to mention that the whole libtool seemed to work quicker
than before.
Thank you all very much and great job!
On a related note, I have been having to add a main function to the
DLL's like so:
#if defined(__MINGW32__) defined(DLL_EXPORT)
int
main(int argc, char* argv[])
{
return 0;
}
#endif
If I do not add this, it does not build the DLL. I'm concerned about
the export of this function, however - if more than one DLL uses this
method, could there be some kind of conflict and/or is there a better
way to deal with this?
Thank you,
Elizabeth
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Whats the latest on libtool and the stub dll libraries?
Earnie Boyd [EMAIL PROTECTED] writes: Not, totally, but it's being worked upon. I've joined the libtool list as well in order to help with resolving the issues with mingw32 host/build/target issues. Hopefully, others that have been actively working with mingw32 libtool issues can speak to this issue. What is your current problem in detail? I.E.: What is failing? I'd like to automate libxml2's build for a mingw system but it's failing when it tries to build the actual library: /bin/sh ./libtool --mode=link i586-mingw32msvc-gcc -g -O2 -Wall -o libxml2.la -rpath /usr/local/lib -version-info 6:24:4 -no-undefined SAX.lo entities.lo encoding.lo error.lo parserInternals.lo parser.lo tree.lo hash.lo list.lo xmlIO.lo xmlmemory.lo uri.lo valid.lo xlink.lo HTMLparser.lo HTMLtree.lo debugXML.lo xpath.lo xpointer.lo xinclude.lo nanohttp.lo nanoftp.lo DOCBparser.lo catalog.lo globals.lo threads.lo c14n.lo xmlregexp.lo xmlschemas.lo xmlschemastypes.lo xmlunicode.lo -lm -lwsock32 rm -fr .libs/libxml2.la .libs/libxml2.* .libs/libxml2.* *** Warning: linker path does not have real file for library -lm. *** 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 libm but no candidates were found. (...for file magic test) *** Warning: linker path does not have real file for library -lwsock32. *** 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 libwsock32 but no candidates were found. (...for file magic test) *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. i586-mingw32msvc-ar cru .libs/libxml2.a SAX.o entities.o encoding.o error.o parserInternals.o parser.o tree.o hash.o list.o xmlIO.o xmlmemory.o uri.o valid.o xlink.o HTMLparser.o HTMLtree.o debugXML.o xpath.o xpointer.o xinclude.o nanohttp.o nanoftp.o DOCBparser.o catalog.o globals.o threads.o c14n.o xmlregexp.o xmlschemas.o xmlschemastypes.o xmlunicode.o i586-mingw32msvc-ranlib .libs/libxml2.a creating libxml2.la (etc... the static library) It went further without the -lm and -lwsock32 but there were many unresolved symbols. I was wondering if libwsock32 was a normal archive but the output of strings suggests it is an import library: (...) _GetAddressByNameA@40 __imp__GetAddressByNameA@40 _GetAcceptExSockaddrs@32 __imp__GetAcceptExSockaddrs@32 _EnumProtocolsW@12 __imp__EnumProtocolsW@12 _EnumProtocolsA@12 __imp__EnumProtocolsA@12 _AcceptEx@32 __imp__AcceptEx@32 dt.o/ 1007767756 0 0 100664 539 ` .text `.data .bss .idata$4 .idata$5 .idata$7 WSOCK32.DLL .text .data .bss .idata$4 .idata$5 .idata$7 __libwsock32_a_iname dh.o/ 1007767756 0 0 100664 651 ` (...) lizzy@shelby:/usr/i586-mingw32msvc/lib$ file libwsock32.a libwsock32.a: current ar archive So I was just wondering about it if the new patches figure out that the stub libraries are not really static. Elizabeth ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
