From: Eduardo M. <ema...@ho...> - 2006-01-19 21:45:35
|
Hello How do I install libtool? I have downloaded a file from ming.org and run mingwPPORT.sh (which was suppsoed to care of everything). I have noticed that wget is not there. Ok, I have get it but if it is going to be the same thing, I will run into trouble again. Is there an option when installing mingw to install very single package available? If not, how do I do it? Many thanks Ed _________________________________________________________________ MSN Messenger: instale grátis e converse com seus amigos. http://messenger.msn.com.br |
From: Ralf W. <Ral...@gm...> - 2006-01-20 08:11:31
|
Hi Eduardo, * Eduardo Mendes wrote on Thu, Jan 19, 2006 at 10:45:18PM CET: > > How do I install libtool? I have downloaded a file from ming.org and run > mingwPPORT.sh (which was suppsoed to care of everything). I have noticed > that wget is not there. Ok, I have get it but if it is going to be the > same thing, I will run into trouble again. > > Is there an option when installing mingw to install very single package > available? If not, how do I do it? Hmm, I don't know of the official way (please correct me here if wrong!), but just downloading the libtool msys-libtool-1.5.tar.bz2 package listed on the MinGW download site and cd /usr tar xvjf /path/to/msys-libtool-1.5.tar.bz2 works for me. By the way, there are newer upstream GNU Libtool versions available, and it should work to install them from plain source, too (say, below /usr/local). Version 1.5.22 has MinGW related fixes, by the way. Hope that helps, Ralf |
From: Keith M. <kei...@to...> - 2006-01-20 11:10:49
|
Ralf Wildenhues wrote, quoting Eduardo Mendes: >> How do I install libtool? I have downloaded a file from ming.org and run >> mingwPPORT.sh (which was suppsoed to care of everything). I have noticed >> that wget is not there. Ok, I have get it but if it is going to be the >> same thing, I will run into trouble again. >> >> Is there an option when installing mingw to install very single package >> available? If not, how do I do it? The current installer provides this capability for the core packages only. For other packages, pick and choose from the package list on the SF project files page, download those you require, and unpack the tarballs into your MinGW installation directory, or in a /usr/local branch of your MSYS tree. (DO NOT, unpack add on packages into the ROOT of your MSYS tree). > Hmm, I don't know of the official way (please correct me here if wrong!), I don't want to put words in Earnie's mouth, but I think the "official" vision for future packages is that the MinGW and MSYS core packages will continue to be distributed as precompiled binaries, while the mingwPORT format will be preferred for add on packages, such as the autotools; (this is *my* preference, anyway). > but just downloading the libtool msys-libtool-1.5.tar.bz2 package listed > on the MinGW download site and > cd /usr > tar xvjf /path/to/msys-libtool-1.5.tar.bz2 > > works for me. I hope that would work in general, but... > By the way, there are newer upstream GNU Libtool versions available, and > it should work to install them from plain source, too (say, below > /usr/local). Version 1.5.22 has MinGW related fixes, by the way. ...the upstream GNU packages will generally be newer than any prepackaged MinGW/MSYS specific releases; in some cases significantly so. With the advent of the mingwPORT framework, mingwPORT packages are now likely to supercede prebuilt binaries, which may not be supported in future. The mingwPORT framework simply provides a mechanism for automating the download, build and installation of such upstream packages, direct from their point of origin, applying any MinGW specific patches which have been found to be necessary. To automate the download of such packages, wget is employed, so it must be installed BEFORE running mingwPORT.sh, if the automatic download feature is to be exploited; there is a prebuilt binary of wget included in wget-1.9.1-mingwPORT.tar.bz2, which should be installed to bootstrap the mingwPORT automated download feature. The current mingwPORT release for libtool is libtool-1.5.14-mingwPORT; if libtool-1.5.22 is now MinGW-clean, then updating that older mingwPORT release may be as simple as changing the version number in the mingwPORT.ini file, and ditching any mingwPORT.patch file. If anyone has successfully built any free software package with MinGW, and could prepare a mingwPORT for it, please feel free to submit this via the mingwPORT submission tracker: http://sourceforge.net/tracker/?group_id=2435&atid=752210 (also accessible from the "MingwPORT Submission" menu link, on MinGW's SF project pages). Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2006-01-20 11:33:37
|
Hi Keith, Thank you for the detailed response! * Keith MARSHALL wrote on Fri, Jan 20, 2006 at 12:10:09PM CET: > Ralf Wildenhues wrote, quoting Eduardo Mendes: > > > By the way, there are newer upstream GNU Libtool versions available, and > > it should work to install them from plain source, too (say, below > > /usr/local). Version 1.5.22 has MinGW related fixes, by the way. > > ...the upstream GNU packages will generally be newer than any prepackaged > MinGW/MSYS specific releases; in some cases significantly so. With the > advent of the mingwPORT framework, mingwPORT packages are now likely to > supercede prebuilt binaries, which may not be supported in future. OK. > The mingwPORT framework simply provides a mechanism for automating the > download, build and installation of such upstream packages, direct from > their point of origin, applying any MinGW specific patches which have > been found to be necessary. To automate the download of such packages, > wget is employed, so it must be installed BEFORE running mingwPORT.sh, > if the automatic download feature is to be exploited; there is a > prebuilt binary of wget included in wget-1.9.1-mingwPORT.tar.bz2, > which should be installed to bootstrap the mingwPORT automated > download feature. Cool. > The current mingwPORT release for libtool is libtool-1.5.14-mingwPORT; > if libtool-1.5.22 is now MinGW-clean, then updating that older mingwPORT > release may be as simple as changing the version number in the > mingwPORT.ini file, and ditching any mingwPORT.patch file. With MinGW-clean, do you mean, may be built under MinGW without any add-on patches? I believe so. It may still fail one or two testsuite tests; I'll fix that in time. If you could point me to a way I could easily see patches that were done against upstream libtool-1.5.14 for the mingwPORT, I could review them and see whether we missed out anything for 1.5.22. Thanks. Cheers, Ralf |
From: Earnie B. <ea...@us...> - 2006-01-20 12:50:35
|
Quoting Ralf Wildenhues <Ral...@gm...>: > > If you could point me to a way I could easily see patches that were done > against upstream libtool-1.5.14 for the mingwPORT, I could review them > and see whether we missed out anything for 1.5.22. Thanks. > If a patch was needed it will be in the mingwPORT tarball for the application and named mingwPORT.patch. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Ralf W. <Ral...@gm...> - 2006-01-20 13:09:51
|
Hi Earnie, * Earnie Boyd wrote on Fri, Jan 20, 2006 at 01:50:30PM CET: > Quoting Ralf Wildenhues <Ral...@gm...>: > > > >If you could point me to a way I could easily see patches that were done > >against upstream libtool-1.5.14 for the mingwPORT, I could review them > >and see whether we missed out anything for 1.5.22. Thanks. > > If a patch was needed it will be in the mingwPORT tarball for the > application D'oh, I could've come to that conclusion myself.. > and named mingwPORT.patch. ..which doesn't seem to be the case for libtool-1.5.14. All the better. :-) Thanks! Ralf |
From: Keith M. <kei...@to...> - 2006-01-20 14:39:57
|
Ralf Wildenhues wrote, quoting me: >> The current mingwPORT release for libtool is libtool-1.5.14-mingwPORT; >> if libtool-1.5.22 is now MinGW-clean, then updating that older mingwPORT >> release may be as simple as changing the version number in the >> mingwPORT.ini file, and ditching any mingwPORT.patch file. > > With MinGW-clean, do you mean, may be built under MinGW without any > add-on patches? Yes. > I believe so. It may still fail one or two testsuite tests; I'll fix > that in time. I can live with a few test suite glitches, if basic functionality isn't compromised. The present mingwPORT implementation doesn't run the test suite anyway; I may fix that one day :-) Don't let me discourage you from fixing any MinGW test suite issues you may find :-) > If you could point me to a way I could easily see patches that were done > against upstream libtool-1.5.14 for the mingwPORT, I could review them > and see whether we missed out anything for 1.5.22. Thanks. Download the tarball, and locate a mingwPORT.patch file in its libtool-1.5.14/mingwPORT directory. I just did that, and there is no such file, so it looks like 1.5.14 was already MinGW-clean. And just for fun, having downloaded it, I changed the version number in mingwPORT.ini, and used it to build and install libtool-1.5.22, without observing any apparent problems. I've never used libtool myself, so I don't consider myself qualified to take it for a test drive. I was going to post this quickly updated package on the mingwPORT submission tracker, but I found that Anatoly Techtonic had beaten me to it, by several weeks! And, he's cleaned up some minor mingwPORT issues which are still on my `round tuit' list! Thanks, Anatoly. You can find Anatoly's libtool-1.5.22-mingwPORT here: http://sourceforge.net/tracker/download.php?group_id=2435&atid=752210&file_id=161017&aid=1389698 I've verified that this behaves just as my own quick update does. If any regular libtool users would like to check it out, and report back either here, or on min...@li..., I'll distribute Anatoly's update in early February -- earlier, if I receive a resounding vote of confidence -- if I don't receive any show stopping criticism in the meantime. Regards, Keith. |
From: Tim T. <ra...@ed...> - 2006-01-20 15:33:31
|
Hello! > You can find Anatoly's libtool-1.5.22-mingwPORT here: > http://sourceforge.net/tracker/download.php?group_id=2435&atid=752210&file_id=161017&aid=1389698 I tried this a while ago and building a static library using autoconf and libtool was stilll possible. I did not see any functional difference between the this and the older version. Building shared libraries still did not work. libtool claimed that there were unresolved symbols. Searching google shows that this may have to do with some special math library condition in MingW (Sounded like math library is faked, but I'm not an expert on this topic). -- Gruß... Tim. |
From: Ralf W. <Ral...@gm...> - 2006-01-20 15:59:12
|
Hi Tim, * Tim Teulings wrote on Fri, Jan 20, 2006 at 04:33:14PM CET: > > > You can find Anatoly's libtool-1.5.22-mingwPORT here: > > http://sourceforge.net/tracker/download.php?group_id=2435&atid=752210&file_id=161017&aid=1389698 > > I tried this a while ago and building a static library using autoconf > and libtool was stilll possible. I did not see any functional difference > between the this and the older version. OK. > Building shared libraries still did not work. libtool claimed that there > were unresolved symbols. Searching google shows that this may have to do > with some special math library condition in MingW (Sounded like math > library is faked, but I'm not an expert on this topic). We have fixed a related bug a while ago. To fix any remaining instances of the issue (or a pretty similar one, as it most likely is), I need very detailed information. 1) Did you add -no-undefined to the link line? If no, please do so. 2) If it still fails, please send as much information as possible: - pointer to complete source tarball, or small reproducible example - configure output - all `./libtool --mode=link' lines plus their output - of the failing `./libtool --mode=link' line, their output with --debug added. - output of `./libtool --config' Without this information, I can't fix much. Cheers, Ralf |
From: Tim T. <ra...@ed...> - 2006-01-24 21:32:38
|
Hello! >>I tried this a while ago and building a static library using autoconf >>and libtool was stilll possible. I did not see any functional difference >>between the this and the older version. > > OK. This was only partly correct. I found out that the 1.5.22 mingPORT seems to install libtool.m4 below my mingw directory instead below by msys directory where all other macro-collections are places. Thus it did not overwrite my old libtool.m4 which in turn resulted in my autoconf scripts still working with old macro-package. I fixed that by simply moving them to the right place. But nevertheless this seems to be a problem in the mingPORT-package. >>Building shared libraries still did not work. libtool claimed that there >>were unresolved symbols. Searching google shows that this may have to do >>with some special math library condition in MingW (Sounded like math >>library is faked, but I'm not an expert on this topic). > > We have fixed a related bug a while ago. To fix any remaining instances > of the issue (or a pretty similar one, as it most likely is), I need > very detailed information. After fixing installation, rebuild the configure stuff (including ltmain.sh and libtool scripts), fixing libm usage, adding -no-undefined and fixing my IMPORT/EXPORT macros I was finally able to build a working DLL! So: I was able to build a DLL using libtool 1.5.22 called from a "normal" Unix-based autoconf package :-) This saved me about 300MB disk space :-) > 1) Did you add -no-undefined to the link line? If no, please do so. It this a "Windows-only" or should this be added for building libtool-based shared-libraries on all systems? -- Gruß... Tim. |
From: Keith M. <kei...@us...> - 2006-01-24 22:17:09
|
On Tuesday 24 January 2006 9:32 pm, Tim Teulings wrote: > I fixed that by simply moving them to the right place. But nevertheless > this seems to be a problem in the mingPORT-package. One of the questions asked, when you run mingwPORT.sh, is where you would like the package to be installed. By default, that is set to /mingw. If you want to overwrite an existing installation elsewhere, e.g. in your MSYS tree, then you must specify the appropriate prefix, when prompted. Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2006-01-26 12:39:59
|
Hi Tim, Hope to actually add some content to this thread now.. * Tim Teulings wrote on Tue, Jan 24, 2006 at 10:32:19PM CET: > > > 1) Did you add -no-undefined to the link line? If no, please do so. > > It this a "Windows-only" or should this be added for building > libtool-based shared-libraries on all systems? -no-undefined carries around some historic ballast, unfortunately. 1) On some systems, notably win32 ones, it is (or was at one time) not possible to create libraries with unresolved symbols (or libtool data assumes so). 2) On some (other) systems, there exist flags to provoke linker failure when not all symbols are resolved, again, when creating a shared library. 3) On a subset of the systems in (2), the flag doesn't or can't work in all situations.[1] For example, because explicit linking against the C standard library or a C++ standard library is broken, or because of numerous other possible deficiencies, that may or may not be controllable by the package author. 4) At some point in Libtool history, it was deemed that the default setting for creating libraries should be to allow undefined symbols, instead of "to allow undefined symbols if the host platform supports it".[2] 5) Consequence: without `-no-undefined', libtool will not create shared libraries at all on win32 systems at the moment. Common practice in packages is to either use `-no-undefined' unconditionally, or, when that turns out not to work everywhere, to use `-no-undefined' on $host_os systems matching `cygwin*' or `mingw*'.[3] In case of doubt, the latter is pretty safe. Hope that clarifies it a bit. And yes, it would probably be good to have a flag -no-undefined-if-system-needs-it Cheers, Ralf [1] The flag is still very useful for many packages, so not using it would remove useful functionality for a lot of people. [2] There is actually an argument to support this: what if the system evolves and allows undefined symbols at some point in the future? Should the libtool default change then? How would people know? [3] libtool.m4 disallows also on `beos*', but a comment states that this may not actually be true in every case. |
From: Ralf W. <Ral...@gm...> - 2006-01-20 16:09:10
|
Hi Keith, * Keith MARSHALL wrote on Fri, Jan 20, 2006 at 03:37:11PM CET: > Ralf Wildenhues wrote, quoting me: > > > I believe so. It may still fail one or two testsuite tests; I'll fix > > that in time. > > I can live with a few test suite glitches, if basic functionality isn't > compromised. No, most things should work fine. > The present mingwPORT implementation doesn't run the test > suite anyway; I may fix that one day :-) Let me tell you, it takes long. Shell and fork/exec performance differences are huge when compared to non-win32 *nix systems. > Don't let me discourage you > from fixing any MinGW test suite issues you may find :-) I know of two failures which we have discussed on the libtool lists but not fixed yet; that will likely happen only after MSVC support is done. Peter Ekberg has done very much good work on adding decent support for MSVC/MinGW in Libtool; I hope to be able to merge his outstanding patch soon, after a couple more issues are resolved. This will change things a bit for GCC/MinGW in Libtool, too, so we need to be careful not to break anything. Also, CVS HEAD Libtool has a couple of MinGW-related improvements compared to branch-1-5 (we've discussed about some before, I believe; for another, performance of the libtool script is a bit better). Cheers, Ralf |
From: Tim T. <ra...@ed...> - 2006-01-25 06:29:59
|
Hello! > One of the questions asked, when you run mingwPORT.sh, is where you would > like the package to be installed. By default, that is set to /mingw. If you > want to overwrite an existing installation elsewhere, e.g. in your MSYS tree, > then you must specify the appropriate prefix, when prompted. OK, but can libtool work without msys installed? Or does my problem only exist because I already made the same error when installing the 1.5.6 version? Would have everything worked if I installed all libtool version to mingw (search paths etc). I think I remember that I had problems when installing things into the wrong directory (ming<->msys). -- Gruß... Tim. |
From: Earnie B. <ea...@us...> - 2006-01-25 12:30:37
|
Quoting Tim Teulings <ra...@ed...>: > Hello! > >> One of the questions asked, when you run mingwPORT.sh, is where you >> would like the package to be installed. By default, that is set to >> /mingw. If you want to overwrite an existing installation >> elsewhere, e.g. in your MSYS tree, then you must specify the >> appropriate prefix, when prompted. > > OK, but can libtool work without msys installed? No. > Or does my problem only exist because I already made the same error > when installing the 1.5.6 version? Would have everything worked if I > installed all libtool version to mingw (search paths etc). I think I > remember that I had problems when installing things into the wrong > directory (ming<->msys). > The autotools chain requires that all of the tools have the same prefix. So if you rebuild autoconf, automake and libtool with a prefix of /mingw then yes installing to /mingw should work. But would might want to clean up your msys paths. The requirement for /bin being reserved for MSYS goes away with version 1.0.11. I am planning to spend a few moments of time in April and May to establish a stable baseline of code for msys-1.0.11 and upload a candidate. There are some items committed to HEAD that will not be included and may be removed. However, the snapshot release is stable, I use it daily with /bin containing my MinGW binaries. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Keith M. <kei...@to...> - 2006-01-25 12:56:38
|
Earnie Boyd wrote: > The autotools chain requires that all of the tools have the same > prefix. So if you rebuild autoconf, automake and libtool with a > prefix of /mingw then yes installing to /mingw should work. But > would might want to clean up your msys paths. Since the msysDTK originally put these packages into the MSYS tree, maybe it's not so clever to set /mingw as the default installation path for the respective mingwPORTs. Since MSYS is officially named as a prequisite for installing any mingwPORT, and since these three mingwPORT packages supercede the earlier msysDTK versions, would it not be more sensible to set the old msysDTK prefix as the default installation path, in each of these three mingwPORTs? I have autoconf-2.59 in my MSYS tree, rather than my MinGW tree, so that would suit me admirably. What would other users prefer? Regards, Keith. |
From: Greg C. <chi...@co...> - 2006-01-25 14:04:22
|
On 2006-1-25 12:51 UTC, Keith MARSHALL wrote: > > Since the msysDTK originally put these packages into the MSYS tree, > maybe it's not so clever to set /mingw as the default installation > path for the respective mingwPORTs. Since MSYS is officially named > as a prequisite for installing any mingwPORT, and since these three > mingwPORT packages supercede the earlier msysDTK versions, would it > not be more sensible to set the old msysDTK prefix as the default > installation path, in each of these three mingwPORTs? I agree. Perhaps a name like "msysPORT" would have made this clearer, though it's probably too late to change that now. > I have autoconf-2.59 in my MSYS tree, rather than my MinGW tree, so > that would suit me admirably. What would other users prefer? Yes, certainly, /mingw/ and /msys/ should be kept distinct. I'd suggest: - if a file is required for compiling or linking a 'hello' or 'winhello' program in your favorite language, regardless of what shell you use, then it belongs in /mingw/ - if a file can't be used without MSYS, then it belongs in /msys/ - a library that would need to be recompiled for use with a different gcc version (say, because of a C++ ABI incompatibility) probably ought to be installed in /mingw/ by default - in any other case, /msys/ is probably better than /mingw/ as a default installation directory |
From: Keith M. <kei...@to...> - 2006-01-26 10:45:59
|
Greg Chicares wrote, quoting me: >> Since the msysDTK originally put these packages into the MSYS tree, >> maybe it's not so clever to set /mingw as the default installation >> path for the respective mingwPORTs. Since MSYS is officially named >> as a prequisite for installing any mingwPORT, and since these three >> mingwPORT packages supercede the earlier msysDTK versions, would it >> not be more sensible to set the old msysDTK prefix as the default >> installation path, in each of these three mingwPORTs? > > I agree. Perhaps a name like "msysPORT" would have made this clearer, > though it's probably too late to change that now. Maybe, maybe not. Obviously any mingwPORT packages "in the wild" are stuck with that name, but they could drop out of sight on the download servers, to be replaced by msysPORTs, if the general consensus is that such a change of naming convention is preferred. There would be some modification to the portmaker required, to support the alternative mingwPORT vs. msysPORT naming conventions, but I don't think that would be a major obstacle. >> I have autoconf-2.59 in my MSYS tree, rather than my MinGW tree, so >> that would suit me admirably. What would other users prefer? > > Yes, certainly, /mingw/ and /msys/ should be kept distinct. I'd suggest: > > - if a file is required for compiling or linking a 'hello' or 'winhello' > program in your favorite language, regardless of what shell you use, > then it belongs in /mingw/ Agreed. > - if a file can't be used without MSYS, then it belongs in /msys/ Also agreed. > - a library that would need to be recompiled for use with a different > gcc version (say, because of a C++ ABI incompatibility) probably > ought to be installed in /mingw/ by default If by this, you mean a library which is only suitable for use with MinGW compiled applications, and is incompatible with any other compiler, then yes, I agree. If it's a library which is compatible only with a specific version of MinGW's gcc, then it belongs in a version specific branch of the /mingw tree. > - in any other case, /msys/ is probably better than /mingw/ as a > default installation directory My own preference is to use /usr/local, within the MSYS tree, (or even simply /local, since in a standard MSYS installation, the two would represent the same directory). Earnie seems to prefer /mingw, since a standard MSYS installation doesn't create the /usr/local directory. As Earnie is effectively the father of MSYS, his preference has been honoured, as the default installation prefix for mingwPORTs. That is guaranteed to provide a working setup, provided all dependencies of each installed mingwPORT are satisfied, since *both* MSYS and MinGW are prerequisites for installing a mingwPORT; it does have the disadvantage, IMO, that the MinGW tree is polluted by applications which are not a part of MinGW itself. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-01-26 12:12:04
|
Quoting Keith MARSHALL <kei...@to...>: > Greg Chicares wrote, quoting me: >>> Since the msysDTK originally put these packages into the MSYS tree, >>> maybe it's not so clever to set /mingw as the default installation >>> path for the respective mingwPORTs. Since MSYS is officially named >>> as a prequisite for installing any mingwPORT, and since these three >>> mingwPORT packages supercede the earlier msysDTK versions, would it >>> not be more sensible to set the old msysDTK prefix as the default >>> installation path, in each of these three mingwPORTs? >> >> I agree. Perhaps a name like "msysPORT" would have made this clearer, >> though it's probably too late to change that now. > > Maybe, maybe not. Obviously any mingwPORT packages "in the wild" are > stuck with that name, but they could drop out of sight on the download > servers, to be replaced by msysPORTs, if the general consensus is that > such a change of naming convention is preferred. > But msysPORT implies that the binary requires msys and it doesn't always. If there are no requirements for sh.exe then there is no requirement for msys beyond building the package. > There would be some modification to the portmaker required, to support > the alternative mingwPORT vs. msysPORT naming conventions, but I don't > think that would be a major obstacle. > No, it shouldn't. >>> I have autoconf-2.59 in my MSYS tree, rather than my MinGW tree, so >>> that would suit me admirably. What would other users prefer? >> >> Yes, certainly, /mingw/ and /msys/ should be kept distinct. I'd suggest: >> >> - if a file is required for compiling or linking a 'hello' or 'winhello' >> program in your favorite language, regardless of what shell you use, >> then it belongs in /mingw/ > > Agreed. > >> - if a file can't be used without MSYS, then it belongs in /msys/ > > Also agreed. > Me three. >> - a library that would need to be recompiled for use with a different >> gcc version (say, because of a C++ ABI incompatibility) probably >> ought to be installed in /mingw/ by default > > If by this, you mean a library which is only suitable for use with MinGW > compiled applications, and is incompatible with any other compiler, then > yes, I agree. If it's a library which is compatible only with a specific > version of MinGW's gcc, then it belongs in a version specific branch of > the /mingw tree. > >> - in any other case, /msys/ is probably better than /mingw/ as a >> default installation directory > > My own preference is to use /usr/local, within the MSYS tree, (or even > simply /local, since in a standard MSYS installation, the two would > represent the same directory). Earnie seems to prefer /mingw, since Just because that is what we agreed to during the early days. > a standard MSYS installation doesn't create the /usr/local directory. > As Earnie is effectively the father of MSYS, his preference has been > honoured, as the default installation prefix for mingwPORTs. That is Again, only because of agreement from MinGW Developers that /mingw would be the correct prefix. > guaranteed to provide a working setup, provided all dependencies of > each installed mingwPORT are satisfied, since *both* MSYS and MinGW > are prerequisites for installing a mingwPORT; it does have the > disadvantage, IMO, that the MinGW tree is polluted by applications > which are not a part of MinGW itself. > That is a side effect of how GCC and binutils finds the default include and library files. The windows port of the build utilities doesn't know how to search /usr/local/include and /usr/local/lib. Therefore, it is necessary to install into a common directory in order to not have to tell the compiler and linker where else to go look. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Earnie B. <ea...@us...> - 2006-01-25 23:15:49
|
Quoting Keith MARSHALL <kei...@to...>: > Earnie Boyd wrote: >> The autotools chain requires that all of the tools have the same >> prefix. So if you rebuild autoconf, automake and libtool with a >> prefix of /mingw then yes installing to /mingw should work. But >> would might want to clean up your msys paths. > > Since the msysDTK originally put these packages into the MSYS tree, > maybe it's not so clever to set /mingw as the default installation > path for the respective mingwPORTs. Since MSYS is officially named > as a prequisite for installing any mingwPORT, and since these three > mingwPORT packages supercede the earlier msysDTK versions, would it > not be more sensible to set the old msysDTK prefix as the default > installation path, in each of these three mingwPORTs? > > I have autoconf-2.59 in my MSYS tree, rather than my MinGW tree, so > that would suit me admirably. What would other users prefer? > Does libtool have a binary in its installation? I think that is why I chose to default to /mingw. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Keith M. <kei...@to...> - 2006-01-26 09:34:56
|
Earnie Boyd wrote: >Quoting Keith MARSHALL: >> Earnie Boyd wrote: >>> The autotools chain requires that all of the tools have the same >>> prefix. So if you rebuild autoconf, automake and libtool with a >>> prefix of /mingw then yes installing to /mingw should work. But >>> would might want to clean up your msys paths. >> >> Since the msysDTK originally put these packages into the MSYS tree, >> maybe it's not so clever to set /mingw as the default installation >> path for the respective mingwPORTs. Since MSYS is officially named >> as a prequisite for installing any mingwPORT, and since these three >> mingwPORT packages supercede the earlier msysDTK versions, would it >> not be more sensible to set the old msysDTK prefix as the default >> installation path, in each of these three mingwPORTs? >> >> I have autoconf-2.59 in my MSYS tree, rather than my MinGW tree, so >> that would suit me admirably. What would other users prefer? > > Does libtool have a binary in its installation? I think that is why > I chose to default to /mingw. Presumably `binary' here means `binary executable', (i.e. `.exe'). Doesn't appear to. All I see in /bin, after installation with a prefix specifying a completely empty sandbox, is a pair of Bourne shell scripts, and a single DLL. Even if there were a `.exe', there's no reason why we couldn't adopt the standard convention of setting the default prefix to `/usr/local', for packages that are expected to run only in an MSYS environment. Of course, that means `/usr/local' must be created, and `/usr/local/bin' should be in the PATH, but that's no big deal; it's how I have my MSYS-1.0.10 installation set up, in any case. Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2006-01-26 09:40:38
|
* Keith MARSHALL wrote on Thu, Jan 26, 2006 at 10:33:49AM CET: > Earnie Boyd wrote: > > > > Does libtool have a binary in its installation? I think that is why > > I chose to default to /mingw. > > Presumably `binary' here means `binary executable', (i.e. `.exe'). libltdl, which is a compiled library, is created and installed along with the Libtool package. Cheers, Ralf |
From: Keith M. <kei...@to...> - 2006-01-26 10:01:52
|
Ralf Wildenhues wrote, quoting me: >>> Does libtool have a binary in its installation? I think that is >>> why I chose to default to /mingw. >> >> Presumably `binary' here means `binary executable', (i.e. `.exe'). > > libltdl, which is a compiled library, is created and installed along > with the Libtool package. Yes, that's the one DLL I mentioned, in my following paragraph :-) Maybe Earnie can clarify this: I know MSYS, prior to 1.0.11, doesn't allow non-MSYS .exe's in /bin; does this restriction also apply to non-MSYS DLLs? AFAIK, there is no such restriction on compiled libraries in /lib. Regards, Keith. |
From: Ralf W. <Ral...@gm...> - 2006-01-26 10:05:24
|
* Keith MARSHALL wrote on Thu, Jan 26, 2006 at 10:57:32AM CET: > Ralf Wildenhues wrote, quoting me: > >>> Does libtool have a binary in its installation? > > libltdl, which is a compiled library, is created and installed along > > with the Libtool package. > > Yes, that's the one DLL I mentioned, in my following paragraph :-) D'oh, so much for open eyes. Sorry 'bout that, Ralf |
From: Earnie B. <ea...@us...> - 2006-01-26 12:23:16
|
Quoting Keith MARSHALL <kei...@to...>: > Earnie Boyd wrote: >> Quoting Keith MARSHALL: >>> Earnie Boyd wrote: >>>> The autotools chain requires that all of the tools have the same >>>> prefix. So if you rebuild autoconf, automake and libtool with a >>>> prefix of /mingw then yes installing to /mingw should work. But >>>> would might want to clean up your msys paths. >>> >>> Since the msysDTK originally put these packages into the MSYS tree, >>> maybe it's not so clever to set /mingw as the default installation >>> path for the respective mingwPORTs. Since MSYS is officially named >>> as a prequisite for installing any mingwPORT, and since these three >>> mingwPORT packages supercede the earlier msysDTK versions, would it >>> not be more sensible to set the old msysDTK prefix as the default >>> installation path, in each of these three mingwPORTs? >>> >>> I have autoconf-2.59 in my MSYS tree, rather than my MinGW tree, so >>> that would suit me admirably. What would other users prefer? >> >> Does libtool have a binary in its installation? I think that is why >> I chose to default to /mingw. > > Presumably `binary' here means `binary executable', (i.e. `.exe'). > Or library, i.e.: libltld.a, libltld.dll.a > Doesn't appear to. All I see in /bin, after installation with a prefix > specifying a completely empty sandbox, is a pair of Bourne shell scripts, > and a single DLL. > And that DLL and its supporting libraries is MSVCRT runtime based when building with MinGW toolset. It would therefore belong in the /mingw prefix. > Even if there were a `.exe', there's no reason why we couldn't adopt > the standard convention of setting the default prefix to `/usr/local', > for packages that are expected to run only in an MSYS environment. Of > course, that means `/usr/local' must be created, and `/usr/local/bin' > should be in the PATH, but that's no big deal; it's how I have my > MSYS-1.0.10 installation set up, in any case. > Yes, there is a reason, the default methods of finding headers and libraries doesn't know how to find /usr/local/include and /usr/local/lib for the mingw set of build tools. The default search path is based on a relative include and lib directory that is based on where those tools exist in the directory tree. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |