Re: MinGW link against an MS Windows import library
Tim Van Holder wrote: Bill Jones wrote: So the basic question is how do I specify a static import library with a *.lib extension to be used by libtool for resolving the symbols provided by a non-libtool DLL when building a dependent DLL with libtool? The trivial solution is of course to make a copy of the third-party .lib file with a .a extension (the file format is identical anyway). Alternatively, you may be able to create a fresh .a from the DLL using 'dllwrap --implib dllname -o libname', but it's likely that that won't have all the necessary symbols. Or just use the dll itself in the link. Note if the library references C++ objects, then you are going to be hard pressed for an easy solution. See www.mingw.org and it's list archives for more information. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW link against an MS Windows import library
Bob Friesenhahn wrote: On Wed, 14 Apr 2004, Bill Jones wrote: I have considered this but do not see it as a practical solution. I do not think that it should be the responsibility of every developer to make a copy of a file simply because the extension is not what libtool likes. The .lib extension is a valid extension to Windows and it seems more appropriate to have libtool conform to that spec under Windows (MinGW/Cygwin in particular) as I am sure that this will occur frequently. Thanks for the response. Is the .lib format really the same as .a? I suspect not since .a suggests that the format is Unix ar format. More or less the same. There may be a few differences. However, binutils have been able to read the MS produced .lib files for some years now. Earnie. -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 1.5.2 released
Bob Friesenhahn wrote: Autoconf now performs two levels of header tests. One level is to check that the header file exists, while the other is to ensure that it can be entirely preprocessed correctly. Probably /lib/cpp is used because it is more work to figure out how to use the compiler as a preprocessor. I thought autoconf already had a macro to test for preprocessor invocation through the compiler frontend. Am I wrong? Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
Scott James Remnant wrote: Not sure whether it's a concern, but generally most packaging systems (RPM springs to mind) do not allow a '-' in the package's upstream version. It's only a concern to the RPM users and maintainers. If it's a CVS snapshot for the next version increment just timestamp the file. So file foo-1.0.tar.gz is a last release, file foo-1.1.tar.gz is to be the next release, then foo-1.1-.MM.DD.tar.gz is a snapshot release. Candidate releases can be named foo-1.1-RC1.tar.gz, incrementing the RC number for subsequent candidate files, if necessary. This scheme makes it easy to understand and explain. Earnie. -- http://www.mingw.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool pre-1.5b tests fail on 9 debian arches
Oh, to the ode of creating new worms... Robert Millan wrote: On Sat, Sep 27, 2003 at 07:26:20PM +0100, Scott James Remnant wrote: Updating to any later version of Libtool is the same amount of work, whether it be the Debian-patched version or not. Most of the time, when build failures occur, the package upstream is using either an insanely out of date version anyway and needs updating whatever the case. That implies asking upstream to update their libtool using upstream libtool in first place, then replacing it with debian's libtool. Asides from the time-consuming effort this represents, the following are examples of problems that may (and usualy do) occur: - libtool.m4 is in a non-standard location or even with a different name; go search for it. - aclocal.m4 won't regenerate with your version of aclocal, and the version upstream used is not present in Debian (e.g: 1.7.6) - configure won't regenerate with your version of autoconf, and the version upstream used is not present in Debian (e.g: 2.53) Add here the fact that upstream is not responsive, and you get a whole can of worms. And this is only _one_ package, porters have to port hundreds of them. Of course, this is only for the situation when upstream updates their upstream libtool for you. When you have to update between different versions of libtool, you'll hit incompatibility errors (missing --tag option, anyone?). Uhm, if you're testing a new version of libtool against all packages, then what you're doing is pointing out what needs changed to support the new version of libtool. Given that the end user of the source does not have to have any of autotools installed (a GNU Standard requirement), the end user just need to execute ``configure'' for the given package. If configure worked previously, then it should work now given a new verions of libtool is installed. If a configure requires an autotools package be installed then the package isn't following the standard. Standards were created for the purpose of making the process the same and thus everyone knows how to do it standardly. If the package isn't owned by FSF, then so be it. If the package is owned by FSF, then it needs to be forced to follow the standard. The reason porters tell maintainers to use the Debian libtool package and not the upstream version is simple... They've generally grabbed me on IRC and we've gone through the build logs, and in some cases our libtool package has been patched and uploaded first. Agreed. When a broken libtool has already been released, there's not much thing to do other than maintaining all these patches in Debian. But if you're use of libtool isn't standard, then perhaps that is the problem. To require all packages to support the new version of libtool at once is not standard. To require the end user to have autoconf, automake, libtool or other maintainer configuration tools on their systems is not standard. To require the packaged configure script to execute properly without these tools installed is standard, nothing else. Getting appropriate patches submitted upstream is a difficult task, and I'm not the only person who believes so, it is something I want to do and have been trying to do, but it's proving hard work to get replies half the time! We should start doing that, and I can help. Just requested copyright papers myself (I assume you've already done that). libtool maintainers: Would you consider giving either Scott or me (preferably both) with CVS access? That'd help a lot getting libtool in shape for all architectures without having to maintain such a debian fork of libtool. And would that get it in shape for everyone else? Why not submit patches that can be reviewed and discussed? [...] If that makes sense? I wasn't intending to infer a new libtool project, I was trying to indicate we wouldn't be able to use the original upstream tar file in the package anymore. Yep, it makes sense now. (it's just the same I've been doing for Bochs) I sent an e-mail over a month ago to open a discussion about this problem, and it went unanswered. Let's reopen it. Ok, it's open. Now, have the patches been submitted for review? Earnie. -- http://www.mingw.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Creating lock file for compilers that don't support -c -o
Paul Jarc wrote: Bob Friesenhahn [EMAIL PROTECTED] wrote: Creating a symbolic link requires testing for an existing file, and then (if the file does not exist) creating a new file, and a directory entry to reference it. This requires multiple network transactions with an opportunity for race-conditions. open() with O_CREAT|O_EXCL also creates a new file, yet that does not subject it to race conditions. symlink() has equivalent semantics to O_CREAT|O_EXCL. It may be that some network filesystems fail to preserve the atomicity; I wouldn't know. But at least for local filesystems, I don't see any problems with symlinks. Problem with symlinks, and hardlinks for that matter, is portability. Not all systems support them. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building static-only or shared-only libraries on a per targetbasis
But what if I want both? Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building static-only or shared-only libraries on a per targetbasis
Ralph Schleicher wrote: Earnie Boyd [EMAIL PROTECTED] writes: But what if I want both? Do nothing special, its the default libtool behavior. If you want to ensure that both kinds of libraries are built for a package, check for enable_shared=yes and enable_static=yes at configure time. My question was relative to the offered patch. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cyclic dependencies
Thomas Maier wrote: Sigh. It's not a perfect world. Quoting myself: I guess as a linux-only user I am kind of ignorant or, well, at least a newbie to portability things. After having spent days reading about that stuff I already suspected linux does things in a rather modern way. But I didn't know it can be *that* bad. Might you be so kind and give me a short hint if linux's behaviour is really extraordinary or if systems with such limited library features are slowly dying away? Hardly dieing. Win32 for example requires dependent libraries to follow the objects that depend on them. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
Albert Chin wrote: I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? Reading through the thread, AC_REQUIRE kept coming to my mind, so no I don't see a problem. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
Charles Wilson wrote: With respect to Bob, Gary's decision to remove it was correct at the time. Unmaintained, untested code should NOT simply be carried along because it might be needed later. It would have made development on actual used and tested platforms [e.g. cygwin/mingw] for the past 21 months much harder, for very little benefit. The old code will always be there -- in CVS archives -- if anybody wants to up-port it. But no one did, and no one was available, and apparently no one needed it until now. That's 21 months of pain, avoided. I'm cool with that. Amen, preach it brother. My sentiments exactly. Also wrt Bob, concerning mingw vs cl: IMO, if you're using cl and relying on its non-standard extensions to C and C++, then you are obviously not trying to write portable code. In that case, you should simply use the MSVC support for building DLLs and static libs, and NOT use libtool or autoconf or automake at all. Since you're not worried about portability, use the tools MS provides to make your life easier; why go thru the pain of creating a *build* system that is portable, when your *code* is not? The autotools are about portability. Well the autotools are to try to make portability easier for the non-portable parts of various environments. I don't see this any different from any of the rest of the support we do based on system specifications. I suggest for good examples for support for cl that you look at what Mo DeJong has done with SourceNavigator. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take 3]
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
Earnie.
Charles Wilson wrote:
Okay, this version
1) puts lt-foo.c into .libs
2) libtool --mode=clean does the right thing --- cleans up foo,
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever else it already
took care of.
3) lt-foo.c actually passes its own arguments to the shell wrapper -- it
didn't, before. (Oops)
libtool regression tests: no new failures (on cygwin)
briefly tested on another project; worked fine.
Binary packages for cygwin (libtool-devel-20030103-4,
libltdl3-20030103-4) available by pointing setup.exe at
http://www.neuro.gatech.edu/users/cwilson/cygutils/testing/
--Chuck
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/ltmain.in,v
retrieving revision 1.318
diff -u -r1.318 ltmain.in
--- ltmain.in 1 Jan 2003 01:57:47 - 1.318
+++ ltmain.in 13 Jan 2003 04:48:39 -
@@ -4284,6 +4284,207 @@
outputname=`echo $outputname|${SED} 's,.exe$,,'` ;;
*) exeext= ;;
esac
+ case $host in
+ *cygwin* | *mingw* )
+ cwrappersource=`echo ${objdir}/lt-${output}.c`
+ cwrapper=`echo ${output}.exe`
+ $rm $cwrappersource $cwrapper
+ trap $rm $cwrappersource $cwrapper; exit 1 1 2 15
+
+ cat $cwrappersource EOF
+
+/* $cwrappersource - temporary wrapper executable for $objdir/$outputname
+ Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
+
+ The $output program cannot be directly executed until all the libtool
+ libraries that it depends on are installed.
+
+ This wrapper executable should never be moved out of the build directory.
+ If it is, it will not operate correctly.
+
+ Currently, it simply execs the wrapper *script* /bin/sh $output,
+ but could eventually absorb all of the scripts functionality and
+ exec $objdir/$outputname directly.
+*/
+EOF
+ cat $cwrappersourceEOF
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include malloc.h
+#include stdarg.h
+#include assert.h
+
+#if defined(PATH_MAX)
+# define LT_PATHMAX PATH_MAX
+#elif defined(MAXPATHLEN)
+# define LT_PATHMAX MAXPATHLEN
+#else
+# define LT_PATHMAX 1024
+#endif
+
+#ifndef DIR_SEPARATOR
+#define DIR_SEPARATOR '/'
+#endif
+
+#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
+ defined (__OS2__)
+#define HAVE_DOS_BASED_FILE_SYSTEM
+#ifndef DIR_SEPARATOR_2
+#define DIR_SEPARATOR_2 '\\'
+#endif
+#endif
+
+#ifndef DIR_SEPARATOR_2
+# define IS_DIR_SEPARATOR(ch) ((ch) == DIR_SEPARATOR)
+#else /* DIR_SEPARATOR_2 */
+# define IS_DIR_SEPARATOR(ch) \
+(((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
+#endif /* DIR_SEPARATOR_2 */
+
+#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
+#define XFREE(stale) do { \
+ if (stale) { free ((void *) stale); stale = 0; } \
+} while (0)
+
+const char *program_name = NULL;
+
+void * xmalloc (size_t num);
+char * xstrdup (const char *string);
+char * basename (const char *name);
+char * fnqualify(const char *path);
+char * strendzap(char *str, const char *pat);
+void lt_fatal (const char *message, ...);
+
+int
+main (int argc, char *argv[])
+{
+ char **newargz;
+ int i;
+
+ program_name = (char *) xstrdup ((char *) basename (argv[0]));
+ newargz = XMALLOC(char *, argc+2);
+ newargz[0] = xstrdup(/bin/sh);
+ newargz[1] = fnqualify(argv[0]);
+ /* we know the script has the same name, without the .exe */
+ /* so make sure newargz[1] doesn't end in .exe */
+ strendzap(newargz[1],.exe);
+ for (i = 1; i argc; i++)
+newargz[i+1] = xstrdup(argv[i]);
+ newargz[argc+1] = NULL;
+ execv(/bin/sh,newargz);
+}
+
+void *
+xmalloc (size_t num)
+{
+ void * p = (void *) malloc (num);
+ if (!p)
+lt_fatal (Memory exhausted);
+
+ return p;
+}
+
+char *
+xstrdup (const char *string)
+{
+ return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) : NULL
+;
+}
+
+char *
+basename (const char *name)
+{
+ const char *base;
+
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+ /* Skip over the disk name in MSDOS pathnames. */
+ if (isalpha (name[0]) name[1] == ':')
+name += 2;
+#endif
+
+ for (base = name; *name; name++)
+if (IS_DIR_SEPARATOR (*name))
+ base = name + 1;
+ return (char *) base;
+}
+
+char *
+fnqualify(const char *path)
+{
+ size_t size;
+ char *p;
+ char tmp[LT_PATHMAX + 1];
+
+ assert(path != NULL);
+
+ /* Is it qualified already? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+ if (isalpha (path[0]) path[1] == ':')
+return xstrdup (path);
+#endif
+ if (IS_DIR_SEPARATOR (path[0]))
+return xstrdup (path);
+
+ /* prepend the current directory */
+ /* doesn't handle '~' */
+ if (getcwd (tmp, LT_PATHMAX) == NULL)
+lt_fatal (getcwd failed);
+ size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
+ p = XMALLOC(char, size);
+ sprintf(p, %s%c%s, tmp,
Re: Wrong path at linking
Szekely Izabella wrote: Hy! I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 7.3. You should at least try it with newest released versions of these softwares. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...[make install DESTDIR=]
Charles Wilson wrote: Also, since this is probably an 'is_absolute' check, it should really be [\\/]* | ?:[\\/]* ) (cfr the File System Conventions chapter in the autoconf manual's portability section). This part won't work. It's possible we need a separate case for A:style paths. Because the rest of the patch does: + add_dir=-L$inst_prefix_dir$libdir $add_dir E.g. prepend the inst_prefix. But A:/inst_prefix/A:/usr/lib is NOT a valid path; for A:style paths you'd need to strip the drive specifier from $libdir before prepending $inst_prefix... Help solicited... IMO, it's not worth supporting. A requirement of libtool and other autotools is a POSIX shell, so ... Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
EXEEXT and -link
There's a problem in that libtool directs the binary output to the .libs directory with a script built to execute the binary. The script does not and cannot have the .exe extention. So the question is, how to go about resolving the issue? The issue is the fact that the make target is modified by the EXEEXT variable. Therefore the target isn't complete when doing things like `make check' or `make install'. Make therefore builds the binaries again. As a resolution, should libtool.m4 capture the value of EXEEXT into it's own variable (e.g.: lt_EXEEXT) and reset EXEEXT to null? Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Library creation command
Kevin Ryde wrote: Olaf Weber [EMAIL PROTECTED] writes: Shouldn't that be ARFLAGS, just as we have CFLAGS not C_FLAGS. That seems to be the canonical name. Libtool uses AR_FLAGS currently. Whichever is adopted it'd be nice for them to be the same. Then libtool is wrong. Based on the GNU make manual it should be ARFLAGS. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Deprecate AC_LIBTOOL_WIN32_DLL?
Charles Wilson wrote: The one remaining niggle is this: you *must* specify -no-undefined, or libtool won't even attempt to build a DLL. I agree. But anyway, -no-undefined is a whole separate issue. As far as AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed. However, given that there are a lot of projects out there that probably have it in their configure.in's already, perhaps you should leave a dummy (empty) definition? Or is that not kosher libtool procedure? Isn't there a method in autoconf to define the macro as deprecated so that a warning is issued? Ah yes: File: autoconf.info, Node: Obsoleting Macros, Next: Coding Style, Prev: Depe\ ndencies Between Macros, Up: Writing Autoconf Macros Obsoleting Macros = Configuration and portability technology has evolved over the years. Often better ways of solving a particular problem are developed, or ad-hoc approaches are systematized. This process has occurred in many parts of Autoconf. One result is that some of the macros are now considered obsolete; they still work, but are no longer considered the best thing to do, hence they should be replaced with more modern macros. Ideally, `autoupdate' should substitute the old macro calls with their modern implementation. Autoconf provides a simple means to obsolete a macro. - Macro: AU_DEFUN (OLD-MACRO, IMPLEMENTATION, [MESSAGE]) Define OLD-MACRO as IMPLEMENTATION. The only difference with `AC_DEFUN' is that the user will be warned that OLD-MACRO is now obsolete. If she then uses `autoupdate', the call to OLD-MACRO will be replaced by the modern IMPLEMENTATION. The additional MESSAGE is then printed. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: On Mon, 14 Oct 2002, Max Bowsher wrote: I floated an idea on how to get around that: Adjust the libtool invocation command (as determined in libtool.m4) to be libtool --bindir=$(bindir) (or perhaps with appropriate quoting). The idea being that when used from an autoconf-based makefile (is it even possible to do otherwise, now there is no ltconfig?), the make variable bindir is passed on to libtool. Kludgy, yes, but better than ../bin. Of course, libtool would need to detect an invalid bindir and fall back on ../bin. I haven't fully worked this through yet, though, as I've just started university, so am a bit busy, and to top it off, my hard drive is making loud clicking noises and bluescreening my laptop from time to time. Be very careful about your assumptions! Libtool is certainly usable all by itself and may be used to install packages into a different directory from the one it is installed in. Libtool only needs autoconf in order to be installed, and is delivered from the FSF as a configurable stand-alone package. In a perfect world, every system would come with a perfectly working libtool, and packages wouldn't need to worry about including it, or configuring it. So what! The FSF standard is to use $(bindir) for binary installation. It even states this in the make documentation. The idea of supporting a --bindir option is tempting, but then 'libtool --mode=install' stops looking like a simple install program, and in fact, the --bindir option would need to be passed for several different phases of libtool operation since it would influence the content of the library.la file. Since Windows may be the only OS benefiting from this, we could have a case of the tail wagging the dog. Would bindir be an environment variable if libtool is being executed from make? If not, setting a variable in the libtool.m4 that configure sets works. I prefer that over a switch, with a default value for the variable of ../bin. If bindir is passed to libtool through the environment then use ../bin if bindir isn't present. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: Proposed libtool patch for MinGW
Max Bowsher wrote: Bob Friesenhahn wrote: The MinGW patch uses libbase-number.dll for DLL naming, I thought the consensus was base-number.dll (no lib)? Or am I remembering wrongly? I prefer Bob's method. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Well, shouldn't both use $(bindir) to install the dll into? Earnie. Bob Friesenhahn wrote: What directory should MinGW DLLs be installed in? Cygwin installs using the offset ../bin from the directory where the .dll.a file is installed. Should libtool behave the same way under MinGW? This seems to make sense as long as Unixish behavior is what is expected by MinGW users. However, the intended purpose of MinGW is somewhat different than Cygwin. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mingw-msys mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mingw-msys ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Elizabeth Barham wrote: 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. 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? Do we have the option of switching between NT and w9x? With Cygwin and MSYS, unmae tacks it on the system name. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-msys] Re: MinGW libtool DLL failure
Elizabeth Barham wrote: What is the MSYS-team's view on this? I'm fine with it and will support the change to a constant. Should that constant be adjusted based on w9x vs NT? Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Elizabeth Barham wrote: 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? With the link line fully qualified with all of the system libraries and objects you could just use ld directly. It would be better, IMO, though to remove the system libraries from the link command and allow g[cc|++] to add the appropriate system libraries so that if some new system library is added, the package won't need to worry about it. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: Cygwin does not have these problems so we have a working example. As I've stated before, the workings parts are the same between MinGW and Cygwin with regard to producing the end result. AFA libtool is concerned the two are equal. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Bob Friesenhahn wrote: On Thu, 10 Oct 2002, Boehne, Robert wrote: The only thing that troubles me about the link line Bob posted is that a .dll is specified in the link, not the corresponding .lib. I'm not a Windows guru, but I thought that you never link to a dll directly, but to the .lib that is created when the dll is. This, of course, is possible via the wonders of libtool. Libtool should hide the fact that a .lib or .a (or whatever) is actually used under the covers. In fact, Microsoft compilers, Cygwin, and MinGW appear to use different naming schemes for these link libraries. Both Cygwin and MinGW should use .dll.a for shared import library and should use .a for static library. Both Cygwin and MinGW will find foo.lib for -lfoo as a last resort if it exists in the library search path. Both Cygwin and MinGW will find foo.dll to satisfy -lfoo if nothing libfoo.dll.a, libfoo.a or foo.lib doesn't exist and foo.dll is in the library search path. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Earnie Boyd wrote: Bob Friesenhahn wrote: On Thu, 10 Oct 2002, Boehne, Robert wrote: The only thing that troubles me about the link line Bob posted is that a .dll is specified in the link, not the corresponding .lib. I'm not a Windows guru, but I thought that you never link to a dll directly, but to the .lib that is created when the dll is. This, of course, is possible via the wonders of libtool. Libtool should hide the fact that a .lib or .a (or whatever) is actually used under the covers. In fact, Microsoft compilers, Cygwin, and MinGW appear to use different naming schemes for these link libraries. Both Cygwin and MinGW should use .dll.a for shared import library and should use .a for static library. Both Cygwin and MinGW will find foo.lib for -lfoo as a last resort if it exists in the library search path. Both Cygwin and MinGW will find foo.dll to satisfy -lfoo if nothing libfoo.dll.a, libfoo.a or foo.lib doesn't exist and foo.dll is in the library search path. I should also mention that a static library can be used to resolve symbols for the .dll file. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MinGW libtool DLL failure
Earnie Boyd wrote: Earnie Boyd wrote: Bob Friesenhahn wrote: On Thu, 10 Oct 2002, Boehne, Robert wrote: The only thing that troubles me about the link line Bob posted is that a .dll is specified in the link, not the corresponding .lib. I'm not a Windows guru, but I thought that you never link to a dll directly, but to the .lib that is created when the dll is. This, of course, is possible via the wonders of libtool. Libtool should hide the fact that a .lib or .a (or whatever) is actually used under the covers. In fact, Microsoft compilers, Cygwin, and MinGW appear to use different naming schemes for these link libraries. Both Cygwin and MinGW should use .dll.a for shared import library and should use .a for static library. Both Cygwin and MinGW will find foo.lib for -lfoo as a last resort if it exists in the library search path. Both Cygwin and MinGW will find foo.dll to satisfy -lfoo if nothing libfoo.dll.a, libfoo.a or foo.lib doesn't exist and foo.dll is in the library search path. I should also mention that a static library can be used to resolve symbols for the .dll file. And to complicate it more, static objects (i.e.: objects that aren't exported from the dll) can be stored in the same library as the import objects for the dll. The libcygwin1.a library contains such objects for an example. In this case the name should be reflective toward the static members, in other words libfoo.a. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.4.3
Paolo Bonzini wrote: Wouldn't it be better to get libtool 1.5 out the door? The resources required to achieve a releasable product are similar and CVS libtool already contains most of the fixes that would go into a 1.4.3. But it also contains more features. Releasing 1.5 should be done by the maintainers, not by a community process; instead I think that such a process is perfectly valid to review patches and ChangeLogs and put them together. The community are the maintainers, therefore a maintainer has spoken for a minor version increment, rather than a patch release increment. Enough has changed to increment the minor version number. Yes, libtool would-be-1.5 has been used by gcc at least since 3.0, so it should be pretty good, but I think that it is easier (in terms of brainwork, not of needed resources) to do a definitive 1.4.x release. Since I'm one of the community, I suggest the release to be 1.5 and that Akim's suggestion for AC_PREREQ a strong point. Perhaps, both a 1.4.3 and a 1.5 where 1.4.3 does a AC_PREREQ 2.13. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Shared C++ libraries on AIX
Ossama Othman wrote:
Hi,
On Mon, Oct 07, 2002 at 07:01:04PM +0200, Martin Frydl wrote:
progname=`$echo $0 | ${SED} 's%^.*/%%'`
The problem is with SED variable, it is not defined anywhere in libtool
script. I think the CVS version is currently unstable.
Did you run aclocal in your package to pull in the latest libtool M4
macros? Some of libtool's functionality is now at done at
`configure'-time, meaning that you have to pull in the latest libtool
M4 macros.
Which also means that you must replace the libtool.m4 in the package
with the CVS version libtool.m4.
Earnie.
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] libtool and Mingw DLLs - bindir/libdir solution - requesting comments
Max Bowsher wrote: I've thought of a way to reliably get bindir from a Makefile. In libtool.m4, the command line to invoke libtool is defined - we can add --bindir=$(bindir) to it, so that libtool knows explictly what the bindir is, even when overridden at 'make install' time. Any comments welcome, Sounds like a meritable plan. Write it up and post the patch. Earnie. ___ 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?
Elizabeth Barham wrote: 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. Please, use cvs diff -u3p. 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. You need a proper ChangeLog entry. 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])])]) That's all there is?! ;) Looks, good. Thanks, Earnie. ___ 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?
Elizabeth Barham wrote:
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
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.
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.
Earnie.
___
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?
Elizabeth Barham wrote: Hi, A while back, Bob mentioned running into some trouble linking a dll with the stub lib*.a libraries: http://mail.gnu.org/pipermail/libtool/2002-June/006401.html and has contributed some patches to libtool (whether in regards to this I do not know). Anyway, I, too, recently had a similar error as what Bob mentioned in the previous email cited above. So, I am curious as to whether or not the kink has been ironed out. 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? Earnie. ___ 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?
Elizabeth Barham wrote: 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 If course -lm isn't needed for mingw32, there are 3rd party libraries that can be built to provide one though. The easy work-around is to remove the -lm from the list of libraries in the Makefile. The permanent fix would be a rework of the autoconfistification for libxml2 to not include the -lm for target *mingw32*. 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. It would need -lwsock32 or -lws2_32 to resolve the unresolved symbols. Static libraries can use shared library 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. I don't understand the point here. Earnie. ___ 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?
Oscar Fuentes wrote: Guido Draheim [EMAIL PROTECTED] writes: '-lm' does not exist on win32, There is a libm.a on MinGW's lib directory. Seems it is a dummy library for those *nix builds that uses -lm. Oh, yes, I forgot about that. Should this be removed? Here's the contents: $ nm /mingw/lib/libm.a _libm_dummy.o: b .bss d .data t .text b ___mingw_libm_dummy Earnie. P.S.: Oscar, please be sure to keep libtool in the distro of the Reply-To munging. ___ 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?
Hmm..., if libtool.m4 exists in the package, make sure you replace it with a copy from the CVS and execute aclocal again. Earnie. Elizabeth Barham wrote: 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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool Win32
David Olofson wrote: However, it's still a very bad idea to compile tools as part of the application build process. ;-) Right, if you want to install implib as part of distributable resource when target == some win32 platform (Cygwin, MinGW, MSVC, etc.) fine, but don't create it in every .libs/ directory. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool Win32
David Olofson wrote: That brings up another interesting point: If impgen was to be compiled when installing libtool, wouldn't that result in the same problem? I mean, impgen should only build when you're installing libtool for a cross compiler - and then you're in that darn cross compiler environment again! *heh* How would one get around that? Having impgen be installed for the host system would work as long as the target is kept in mind. So, your impgen would be built to execute on Linux but target binary libraries for Win32. Much the same way GCC does it now. You could use dlltool to create the same files as impgen so that impgen isn't needed AFAIK. I could see keeping impgen if it is possible to code it to target a different system other than Win32. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Intel icc and shared libs
[EMAIL PROTECTED] wrote: == bw == Bill Wendling [EMAIL PROTECTED] writes: bw # How to pass a linker flag through the compiler. wl= bw to: bw # How to pass a linker flag through the compiler. wl=-Wl, bw That might help things... On the version of icc that I use, it's more like wl=-Qoption,ld, Curious, what kind of System, i.e. POSIX/Bourne shell, are you using to accomplish your native use? I'm assuming here that icc is a Win32 compiler, sorry if I'm wrong. I ask because I have a product that can be configured for your use as a native icc host/build system. Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: libbfd, libtool Win32
Guido Draheim wrote: Just my point. It's nice that cygwin wants to emulate the unix behaviour to a degree that even data-symbols are im/exported in the usual manner, that's different with mingw-software where I do take the burden to make it ready to run in crippled environment, just to make it more native. That's the whole point of it anyway... and therefore, making software windows-ready means to look for the difference in datasymbol export (and to not use them, actually). I won't make use of that cygwin feature since I know of problems with compiling the dll sources with msvc and borland and watcom - and I am quite sure they don't have the same scheme of wrapping the unixish stuff in DLLs, like exported data symbols. Hmm... Well, the gcc source is the same for both Cygwin and MinGW, AFAIK, at least that's what I get out of Danny Smith and Chris Faylor posts. So, what works for Cygwin should work for MinGW. Now, interoperation between MSVC, Watcom, Borland, etc, and GCC; is it doable, and if doable, is it worth it? Earnie. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: cygwin libtool breakage
Robert Collins wrote: I _did_ have autoconf CVS HEAD at one point, I reverted to 2.13 to be in line with other users, and I haven't upgraded again yet. I don't recall this problem from back then.. if that helps at all :] Rob Hi Robert, Don't know if you follow the autoconf list but you might give the google.com a try with this http://www.google.com/search?hl=enlr=safe=offq=AC_EXEEXT+2001+site%3Agnu.org -- Earnie. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Forbidden strings
--- Akim Demaille [EMAIL PROTECTED] wrote: "Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes: Alexandre On Nov 6, 2000, Earnie Boyd [EMAIL PROTECTED] wrote: Why not just prefix the reserved autoconf variables with a `_' character? Alexandre autoconf used to use just AC_/ac_. Now, it's claiming Alexandre ownership of all of A?_. That looks a little bit Alexandre exagerated to me. Still, why should we struggle for AR_ and not for AC_? How can we decide that users must not use AC_ in their configure.in? I personally think it is saner to get all these A?_* names, because we already use many of them and will use even more in the future, and to provide a means to declare what are the symbols to allow, as compared to catching only a random number of A[CHUMS]_ and provide no escape. But, neither of you answered my question. Why not use `_' to prefix A?_* names? You can then declare that the user is incorrect as _A?_* is a vendor variable! I as a user should be allowed to declare A?_ as a variable or function. I as a user should never declare _A?_ as a variable or function. Cheers, ===== Earnie Boyd mailto:[EMAIL PROTECTED] --- http://earniesystems.safeshopper.com --- --- Cygwin: POSIX on Windows http://gw32.freeyellow.com/ --- --- Minimalist GNU for Windows http://www.mingw.org/ --- __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one Place. http://shopping.yahoo.com/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
