Re: revised patch for glib compilation on cygwin with POSIX runtime

2001-02-20 Thread Tor Lillqvist
Gary V. Vaughan writes: > If libtool doesn't already find non-libtool libraries on mingw, then that is > a bug. libtool works with non-libtool libraries on the other architectures > to which it has been ported. Patches gratefully accepted (I think this > should be quite straight forward).

new libtool.m4 patch for cygwin & mingw

2001-02-21 Thread Tor Lillqvist
New try... I changed "lib" to "cyg" in the wrong place. Sorry. Now it should affect only the name of the dll (and related files), I hope. --tml Index: libtool.m4 === RCS file: /cvs/libtool/libtool.m4,v retrieving revision 1.142 diff

Re: revised patch for glib compilation on cygwin with POSIX runtime

2001-02-21 Thread Tor Lillqvist
Here is a suggested patch to libtool.m4. It implements the following: - If the export_symbols file (which has been passed to libtool with the -export-symbols command line switch) already is a .def file, use it as is. - On Cygwin, set libname_spec to cyg$name instead of the default lib$name. - F

Re: new libtool.m4 patch for cygwin & mingw

2001-03-08 Thread Tor Lillqvist
Gary V. Vaughan writes: > The attached files are FYI, and represent the commits I made to HEAD. > + yes,cygwin*) > +    library_names_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | >[sed -e 's/[.]/-/g']`${versuffix}.dll' > +;; > +  yes,mingw*) > +    library_names_s

Re: sys_lib_search_patch_spec/path_separator (Re: Suggested pathes to CVC libtool: Mingw improvement, .rc support)

2001-09-22 Thread Tor Lillqvist
> > b) why is it just bigcaps drive-letters? > > Ditto. Although I guess this comes from the spec file, so maybe more > care _is_ needed after all? It doesn't come from the specs file, remember that the mingw gcc can be installed freely in any location, and the specs file isn't edited when

Suggested pathes to CVC libtool: Mingw improvement, .rc support

2001-09-14 Thread Tor Lillqvist
es (Windows resource files), compiled by the resource compiler (windres in mingw) to .o files. -- Minor bug fix for $PATH elements with spaces in them when looking for nm. -- I think there was some confusion with trailing spaces in $base_compile in ltmain.in? ChangeLog entry: 2001-09-15 To

Libtool patch for mode=install on Cygwin

2001-09-16 Thread Tor Lillqvist
817,6 @@ # If there is no directory component, then add one. case $file in - */* | *\\*) . $file ;; - *) . ./$file ;; + */* | *\\*) . $wrapper ;; + *) . ./$wrapper ;; esac Cheers, Tor Lillqvist ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Problem with finding included ltdll.c and impgen.c on Cygwin

2001-09-16 Thread Tor Lillqvist
In current CVS libtool.m4, the code that outputs the included ltdll.c and impgen.c is indented four spaces. Including the lines with _LT_AC_FILE_LTDLL_C and _LT_AC_FILE_IMPGEN_C. Thus the start marker lines also get indented in the resulting libtool script. However, when libtool goes looking for t

Re: libtool versioning

2010-05-04 Thread Tor Lillqvist
>>> I am not a native English speaker, but I find the use of "may use" a bit confusing in the added text. I would suggest changing some instances of "may use" to "are able to use" and some to "might

Re: Question about relink_command

2010-05-31 Thread Tor Lillqvist
What makes you think the issue relinking is related to would have anything to do with Linux in particular? --tml ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: Speeding up libtool

2005-03-15 Thread Tor Lillqvist
Ralf Wildenhues writes: > Linking is a problem, though: shell wrappers break, I have never liked (or understood...) libtool's shell wrappers or its relinking on Win32. I always use --disable-static, I always run a "make install", and make sure the bin directory of the installation location is in

functions under MinGW

2005-03-16 Thread Tor Lillqvist
Bob Friesenhahn writes: > It turns out that the related functionality provided with > MinGW is hoisted from Cygwin. As such, it has GPL restrictions. Errr, certainly not. Maybe you are thinking of the dirent implementation in MSYS? MSYS *is* a fork of Cygwin. MSYS is an environment for a conf

Re: functions under MinGW

2005-03-16 Thread Tor Lillqvist
Bob Friesenhahn writes: > Yes, I am talking about building using MSYS. Not just *using* MSYS (i.e. using MSYS's shell, sed, m4, awk etc), but *for* MSYS, right? Targetting MSYS is not something one would commonly do, is it? The whole point of MSYS is that it is a runtime used by development tools

Re: Speeding up libtool

2005-03-26 Thread Tor Lillqvist
Robert Ögren writes: > 2. configure.in did not have AC_LIBTOOL_WIN32_DLL which now is required > for OBJDUMP to be set. Hmm. Wasn't AC_LIBTOOL_WIN32_DLL supposed to be deprecated and unnecessary? Or was it just that at some point it was de facto unnecessary but never officially deprecated, and n

Re: Slow shell script execution on Cygwin

2005-04-15 Thread Tor Lillqvist
Just throwing out (or throwing up ;-) some ideas...: Has anybody investigated using busybox on Cygwin? Or something similar? I.e. binding the code for the most common GNU utitilies (sed, m4, gawk, expr, cp, cat, ls, rm, ln, echo) more tightly to the shell, perhaps building them as DLLs, and instea

Re: Compiling with MinGW

2006-08-05 Thread Tor Lillqvist
Bruno Haible writes: > You appear to be using mingw as a development environment. I don't know > whether libtool supports that. If with mingw one combines MSYS, it certainly does. Using MSYS with auto* and libtool is IMHO much more reliable than using Cygwin, MSYS gets less in the way and causes

Re: Compiling with MinGW

2006-08-05 Thread Tor Lillqvist
Bob Friesenhahn writes: > Libtool does support using the MinGW compiler via Cygwin or > MSYS (I have only tried MSYS). Both of these support Unix type paths > and automatically convert to Windows paths for MinGW. I don't think Cygwin does that to the same extent as MSYS. Isn't that the exact

Re: mingw install directory for shared lib

2008-01-08 Thread Tor Lillqvist
Shouldn't plug-in -type shared libraries be built with the -module -avoid-version libtool flags? I think with those flags, such libtool-built DLLs get installed in the libdir of the Makefile in question, not libdir/../bin like normal DLLs. --tml ___ ht

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

2008-04-10 Thread Tor Lillqvist
Let me just point out another, old but apparently not well known, more portable imrovement on libtool, libtool-cache. libtool-cache doesn't replace libtool, but as can be guessed from its name, it just avoids running libtool if the actual shell commands that would be executed by libtool can be know

Distributing .la files in devel packages for Windows?

2008-05-07 Thread Tor Lillqvist
What is the recommendation on distributing .la files in the Windows devel package of some library? Personally I never do it in the software I build and distribute for Win32 (and nobody has complained), but now I have come across one devel package by another guy that does include .la files in additi

Re: printing library version

2009-05-20 Thread Tor Lillqvist
> if I want to print the library version from a program > is it correct to print 2:0:1 or 1.1.0? What exactly do you mean with "library version" ? Note that neither the libtool triple current:revision:age nor the Linux-style suffix it causes to be appended after the ".so" correspond to the actual

Re: printing library version

2009-05-21 Thread Tor Lillqvist
> Well I've always needed to get the filename (somewhat related to the library > version) when building Windows DLLs that I can prepare a resource.in file, grep '^dlname' libfoo.la | sed -e "s/dlname=//" -e "s/'//g" ? But yeah, this is a chicken-and-egg problem, you want the full DLL name in the

Re: Multipurpose binaries with different names

2009-07-28 Thread Tor Lillqvist
> #ifdef _WIN32 >  executable_name = strrchr (argv[0], '\\'); Bzzt. You have to use the multi-byte character set aware _mbschr() and _mbsrchr() functions from to search for backlashes (or slashes) in "narrow" (char *) system code page strings (for instance, file names) on Windows. The East Asian

Re: different flags for static and shared

2009-08-17 Thread Tor Lillqvist
> Working on this now.  Curious what people think of this, and if there's a > better way that I'm missing (other than ditching MS which unfortunately > isn't an option at the moment). Just offer your libraries only as DLLs... that bypasses this whole mess. That is what many people who distribute

Re: Extend libtool dll namespaces for mingw-w64

2010-01-27 Thread Tor Lillqvist
> I'm not sure that idea for lib{64|32} is so good. Me neither, but, > As I know for 32 bit process  64 bit microsoft windows os will return > %WINDOWS%\SysWOW64 as system folder. For 64 bit process it is > %WINDOWS%\System32 I fail to see what *that* has to do with it. Surely nobody builds any

Re: Extend libtool dll namespaces for mingw-w64

2010-01-28 Thread Tor Lillqvist
> The issue is that libtool > uses the "lib" prefix for both 64bit and 32bit DLLs, and for both mingw > and mingw-w64. Well, my take is that except for people working on the *tools themselves* (meaning gcc, binutils etc), this is not really a problem. Sure, libtool is a tool used by developers, bu

Re: Extend libtool dll namespaces for mingw-w64

2010-01-30 Thread Tor Lillqvist
> That is just not sane engineering practice. > I'd even consider > installing 64bit packages in a separate --prefix from 32bit ones to be > good packaging practice, > GCC is a *special* case, to be fixed in the GCC package. Don't confuse > the compiler+tools special cases with the rest of norma

Suggested minor patches for Win32

2002-04-26 Thread Tor Lillqvist
Hi, For the current CVS libtool, I suggest the following patches: - Pass the --enable-auto-image-base switch to the linker when building a DLL. - Grep case-insentively for drive letters in the gcc -print-search-dirs output. Index: libtool.m4

Re: "Re: libbfd, libtool & Win32" and "Re: Building a MinGW GLibetc..."

2002-09-16 Thread Tor Lillqvist
Guido writes: > Aren't these two interrelated? I thought that the relink step was > done to try to ensure the libs have a different image-base, even > though it might never been implemented that way... Umm, never thought of that. I thought that the relink was done because of some issues with sear

Re: Converting a project to libtool

2002-09-18 Thread Tor Lillqvist
Steve M. Robbins writes: > then you can just reverse-engineer > the computation that libtool does. Then choose values for Current, > Revision, and Age that give you the answer you want. Or choose fresh current, revision, age values that won't cause a clash with your current name now or in the

ASFLAGS handling for dlltool

2002-09-22 Thread Tor Lillqvist
When libool invokes dlltool on mingw (and cygwin), it needs to pass in any ASFLAGS that the client configure.in might have set, because the configure.in might set AS=gcc and ASFLAGS=-c. (If it set just AS="gcc -c" dlltool would try to invoke a program called "gcc -c", sigh. The client configure.in

Re: [Mingw-msys] Re: MinGW libtool DLL failure

2002-10-13 Thread Tor Lillqvist
Earnie Boyd 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. I have experienced that the 8192 (umm, don't remember exactly, some pretty low limit anyhow) wasn't enough for GTK+, and libtool starte

Re: How to disable relink on install?

2003-06-29 Thread Tor Lillqvist
Max Bowsher writes: > If so, relinking is definitely never required on Windows, because *no* path > information is recorded in executables. Hear, hear! > I resorted to disabling that section of code in ltmain.sh with a case > statement. Ditto. --tml _

Re: only static libraries created

2003-09-25 Thread Tor Lillqvist
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

Re: TODO

2004-11-15 Thread Tor Lillqvist
> At first I thought that would be to absorb pkg-config's > functionality into libtool (to avoid duplication of code and > maintenance), Just in case somebody still ponders this, please take into account that pkg-config works even for people on Windows who use MSVC (the command-line tools, not