From: Michael A. <mic...@gm...> - 2009-03-10 04:21:59
|
Ladies and Gentlemen, I recently (and finally) figured a process that worked for building and installing new versions of autotools in msys, though I can't find answers to these questions either on the web (I know they're out there, somewhere :) or on this mailing list. When using the --prefix=/mingw tag, the executables show up in /mingw/bin but not in /bin (obviously). When I run these tools does /mingw/bin get searched before /bin does? If not can I just create symlinks in /bin? Can I remove the files created in temporary directories after making and make installing the autotools, since (I'm assuming) the executables located in /mingw/bin are enough to run the autotools and all the other files got placed where they needed to? For example, I have the source files for autoconf and automake in /home/Mikey, but I built them from the root directory using "/home/Mikey/path/to/configure --prefix=/mingw && make && make install" (not sure if that was the smartest place from which to build...). This left several other files and folders in /home/Mikey. Similarly, I had to build libtool from /home/Mikey/tmp/foo/bar (I may have gone a bit overboard :), and consequently there were extra files in ~/tmp/foo/bar. Can I delete these? Thanks in advance! I know I'm very verbose, but I figure the more information I present on first contact, the more birds we can kill with less stones ;) Regards, Mikey |
From: JonY <10...@gm...> - 2009-03-10 09:46:58
|
On 3/10/2009 12:21, Michael Atkinson wrote: > Ladies and Gentlemen, > > I recently (and finally) figured a process that worked for building and > installing new versions of autotools in msys, though I can't find answers to > these questions either on the web (I know they're out there, somewhere :) or > on this mailing list. > > When using the --prefix=/mingw tag, the executables show up in /mingw/bin > but not in /bin (obviously). When I run these tools does /mingw/bin get > searched before /bin does? If not can I just create symlinks in /bin? Can > I remove the files created in temporary directories after making and make > installing the autotools, since (I'm assuming) the executables located in > /mingw/bin are enough to run the autotools and all the other files got > placed where they needed to? For example, I have the source files for > autoconf and automake in /home/Mikey, but I built them from the root > directory using "/home/Mikey/path/to/configure --prefix=/mingw&& make&& > make install" (not sure if that was the smartest place from which to > build...). This left several other files and folders in /home/Mikey. > Similarly, I had to build libtool from /home/Mikey/tmp/foo/bar (I may have > gone a bit overboard :), and consequently there were extra files in > ~/tmp/foo/bar. Can I delete these? > Hi, You can check by issuing "echo $PATH" in MSYS. The directories listed first would be searched first. The root is a very odd place for a build directory. Its a good idea to use a sibling directory relative the source directory as your working space. Yes, you may also remove the files in the build and source directory after "make install". They are already installed to the directory pointed by the prefix. Moving the installed executables and scripts is not recommended, but ymmv depending on the app itself. > Thanks in advance! I know I'm very verbose, but I figure the more > information I present on first contact, the more birds we can kill with less > stones ;) > Do use proper line spacings and avoid top posting. :) |
From: Keith M. <kei...@us...> - 2009-03-10 19:59:46
|
On Tuesday 10 March 2009 04:21:52 Michael Atkinson wrote: > I recently (and finally) figured a process that worked for building > and installing new versions of autotools in msys, though I can't > find answers to these questions either on the web (I know they're > out there, somewhere :) or on this mailing list. http://thread.gmane.org/gmane.comp.gnu.mingw.user/27824/focus=27838 > When using the --prefix=/mingw tag, the executables show up in > /mingw/bin but not in /bin (obviously). When I run these tools > does /mingw/bin get searched before /bin does? If you run it from a conventionally configured MSYS session, and you haven't reassigned PATH, then yes; (`echo $PATH' should confirm this) > If not can I just create symlinks in /bin? No such thing, on MS-Windows. (Please don't tell me Vista provides them; in spite of Microsoft's claims, it doesn't, in any legitimate semblance of true symlink functionality). > Can I remove the files created in temporary directories after making > and make installing the autotools, Yes, but you will lose the ability to just `make uninstall', if you ever want it; (however, you can reinstate it by simply repeating the configure and make, with identically the same original version of the source, and the same configure options, then `make uninstall'). > since (I'm assuming) the executables located in /mingw/bin are > enough to run the autotools and all the other files got placed where > they needed to? Yes, they should have been. > For example, I have the source files for autoconf and automake > in /home/Mikey, [...] Can I delete these? Yes, subject to the preceding caveat. > Thanks in advance! I know I'm very verbose, but I figure the more > information I present on first contact, the more birds we can kill > with less stones ;) You're welcome. If replying, please post plain text only, not the multipart-alternative of your original; wrap text at between 65 and 72 character line length, and, (in case you thought of it), please don't top-post. -- Regards, Keith. |
From: Robert R. <rr...@bt...> - 2009-03-11 21:20:03
|
Keith Marshall wrote: >> If not can I just create symlinks in /bin? > > No such thing, on MS-Windows. (Please don't tell me Vista provides > them; in spite of Microsoft's claims, it doesn't, in any legitimate > semblance of true symlink functionality). Hard links exist since Windows 2000. Robert Riebisch -- BTTR Software http://www.bttr-software.de/ |
From: Keith M. <kei...@us...> - 2009-03-11 23:08:39
|
On Wednesday 11 March 2009 21:19:46 Robert Riebisch wrote: > >> If not can I just create symlinks in /bin? > > > > No such thing, on MS-Windows. (Please don't tell me Vista > > provides them; in spite of Microsoft's claims, it doesn't, in any > > legitimate semblance of true symlink functionality). > > Hard links exist since Windows 2000. A hard link is *not* a symlink. |
From: Matthew T. <ran...@gm...> - 2009-03-11 23:25:27
|
I guess I'm curious enough to ask, how are junctions, http://en.wikipedia.org/wiki/NTFS_junction_point, different from symbolic links? Matthew |
From: Greg C. <gch...@sb...> - 2009-03-11 23:40:12
|
On 2009-03-11 23:25Z, Matthew Talbert wrote: > I guess I'm curious enough to ask, how are junctions, > http://en.wikipedia.org/wiki/NTFS_junction_point, different from > symbolic links? Here's just one sample query that looks fruitful: http://search.gmane.org/?query=junction+symlink&group=gmane.comp.gnu.mingw.msys |
From: Tuomo L. <dj...@ik...> - 2009-03-12 20:14:18
|
Matthew Talbert wrote: > I guess I'm curious enough to ask, how are junctions, > http://en.wikipedia.org/wiki/NTFS_junction_point, different from > symbolic links? The way I see it, they are essentially file system level symlinks that only support absolute paths. -- Tuomo ... [13:35] < tlatto> goto -10 [13:35] < tlatto> oops [13:46] < gk> thats a lousy password [13:47] < stefan> haha |
From: Robert R. <rr...@bt...> - 2009-03-12 19:35:45
|
Keith Marshall wrote: >> Hard links exist since Windows 2000. > > A hard link is *not* a symlink. It's better than nothing. ;-) We also have junction points. Robert Riebisch -- BTTR Software http://www.bttr-software.de/ |
From: Earnie B. <ea...@us...> - 2009-03-12 20:44:54
|
Quoting Robert Riebisch <rr...@bt...>: > Keith Marshall wrote: > >>> Hard links exist since Windows 2000. >> >> A hard link is *not* a symlink. > > It's better than nothing. ;-) We also have junction points. > MSYS' ln will create a hard link on an NTFS device. If someone is interested in modifying MSYS to use junction points as a symlink I think Cesar wouldn't mind to look at a patch. The junction points will cross drive boundaries and do come in handy. Earnie |
From: Earnie B. <ea...@us...> - 2009-03-13 11:30:03
|
Quoting Earnie Boyd <ea...@us...>: > > Quoting Robert Riebisch <rr...@bt...>: > >> Keith Marshall wrote: >> >>>> Hard links exist since Windows 2000. >>> >>> A hard link is *not* a symlink. >> >> It's better than nothing. ;-) We also have junction points. >> > > MSYS' ln will create a hard link on an NTFS device. If someone is > interested in modifying MSYS to use junction points as a symlink I > think Cesar wouldn't mind to look at a patch. The junction points will > cross drive boundaries and do come in handy. > I discovered something interesting with junction points that is baffling me. I created a junction bar.junction foo.file and while MSYS tools have no problem with reading bar.junction as a file the windows native tools like gvim see it as a directory. Can someone educate me? Earnie |
From: Роман Д. <DXD...@ya...> - 2009-03-13 15:08:54
|
Earnie Boyd <ea...@us...> писал(а) в своём письме Fri, 13 Mar 2009 14:29:37 +0300: > > Quoting Earnie Boyd > <ea...@us...>: > >> >> Quoting Robert Riebisch <rr...@bt...>: >>> It's better than nothing. ;-) We also have junction points. >>> >> >> MSYS' ln will create a hard link on an NTFS device. If someone is >> interested in modifying MSYS to use junction points as a symlink I >> think Cesar wouldn't mind to look at a patch. The junction points will >> cross drive boundaries and do come in handy. >> > > I discovered something interesting with junction points that is > baffling me. I created a junction bar.junction foo.file and while MSYS > tools have no problem with reading bar.junction as a file the windows > native tools like gvim see it as a directory. Can someone educate me? > > Earnie I thought junction points can only point to directories. Roman. |
From: Keith M. <kei...@us...> - 2009-03-13 17:32:57
|
On Friday 13 March 2009 15:08:22 Роман Донченко wrote: > I thought junction points can only point to directories. That's my understanding too; and furthermore, while I believe they can span physically distinct drives or partitions, that is restricted to drives for which the controller is physically connected to the system bus in the local machine. -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2009-03-13 17:36:31
|
Quoting Роман Донченко <DXD...@ya...>: > Earnie Boyd <ea...@us...> > писал(а) в своём письме Fri, 13 Mar 2009 14:29:37 +0300: > >> >> Quoting Earnie Boyd >> <ea...@us...>: >> >>> >>> Quoting Robert Riebisch <rr...@bt...>: >>>> It's better than nothing. ;-) We also have junction points. >>>> >>> >>> MSYS' ln will create a hard link on an NTFS device. If someone is >>> interested in modifying MSYS to use junction points as a symlink I >>> think Cesar wouldn't mind to look at a patch. The junction points will >>> cross drive boundaries and do come in handy. >>> >> >> I discovered something interesting with junction points that is >> baffling me. I created a junction bar.junction foo.file and while MSYS >> tools have no problem with reading bar.junction as a file the windows >> native tools like gvim see it as a directory. Can someone educate me? >> >> Earnie > > I thought junction points can only point to directories. > That's why I'm confused. I would think that MSYS would have an issue with reading the bar.junction file. The vim supplied with MSYS even opens the files for reading. It won't overwrite it and you get a "Not owner" error when using rm. Strange, just strange. Earnie |
From: Tuomo L. <dj...@ik...> - 2009-03-13 22:10:16
|
Earnie Boyd wrote: > Quoting Роман Донченко <DXD...@ya...>: >> I thought junction points can only point to directories. > > That's why I'm confused. I would think that MSYS would have an issue > with reading the bar.junction file. The vim supplied with MSYS even > opens the files for reading. It won't overwrite it and you get a "Not > owner" error when using rm. Strange, just strange. There's a directory icon next to it on explorer.exe. I wonder what sort of flags the OS reports for it (and which flags are checked by the applications). Too lazy to try it myself, right now at least. "Not owner" sounds like a generic permission error mapped to the most likely culprit, though. -- Tuomo ... Two wrongs don't make a right, but three lefts do |