From: Earnie B. <ear...@ya...> - 2002-02-10 16:48:30
|
Prof Abimbola Olowofoyeku wrote: > > On 9 Feb 2002 at 18:08, Earnie Boyd wrote: > > [...] > > Well, I'm down to an interesting problem with symlink conversion and > > MinGW GCC. Guess what the default output file name will be for a > > symlink whose source file name is different than the symlink name and > > you convert the symlink name back to the source file name. I'll give > > you a hint, it's not what make expects. > > Interesting circular problem - do you create a special 'make' for msys, > or do you change msys itself so that it does not convert symlinks. The > latter is a non-starter, since converting the symlinks seems to be one > of the purposes of msys. That leaves few options - amend make so that > it is happy with symlinks or the converted filename, or provide a > switch somewhere to optionally prevent symlink conversion for the > duration of one command. How does that sound? I probably am barking up > the wrong tree, since I don't know msys that well .... > Please post on list and not directly to me. Well the real problem is that I have file foo.c and a symlink bar.c that points to foo.c. So, when using MSYS I `gcc -c bar.c' I end up with a foo.o because MSYS converted bar.c to foo.c and the next phase of the Makefile is to link an executable containing bar.o which doesn't exist. I have the following options I'm considering: 1) What does autoconfiguration do when ln doesn't exist? 2) Should MSYS symlink process copy the file instead of creating the link when the destination basename and source basename are not equal? 3) Should the MinGW version of GCC be changed to read the symlink file and find the appropriate reference? 4) Should I just instruct the user on how to work around the problem? E.G.: Change every occurance of `ln' and/or `ln -s' to `cp -f' in the Makefile. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Prof A. O. <Afr...@bi...> - 2002-02-10 21:07:33
|
On 10 Feb 2002 at 11:47, Earnie Boyd wrote: [...] > Well the real problem is that I have file foo.c and a symlink bar.c that > points to foo.c. So, when using MSYS I `gcc -c bar.c' I end up with a > foo.o because MSYS converted bar.c to foo.c and the next phase of the > Makefile is to link an executable containing bar.o which doesn't exist. > > I have the following options I'm considering: > > 1) What does autoconfiguration do when ln doesn't exist? 'configure' uses 'cp' instead (sets 'LN=cp"). It succeeds in creating the makefile, but stops with an error sometime afterward - something like this; updating cache ./config.cache creating ./config.status creating Makefile creating intl/Makefile creating po/Makefile.in creating fixinc/Makefile creating auto-host.h linking ./intl/libgettext.h to intl/libintl.h ./config.status: ln: command not found configure: error: can not link intl/libintl.h to ./intl/libgettext.h > 2) Should MSYS symlink process copy the file instead of creating the > link when the destination basename and source basename are not equal? This would be consistent with what 'configure' does. But you might end up with multiple copies of huge files, so this should probably not be the default behaviour - for 'configure' to do it is one thing (you only use that when building something from source, and you will usually clean up everything afterwards) - but for it to be the default 'ln' behaviour might end up cluttering a user's hard disk. But how one would be able to distinguish between when to have this behaviour and when not to, is a problem. Perhaps it could be the default behaviour after all ! >3) > Should the MinGW version of GCC be changed to read the symlink file and > find the appropriate reference? This would be extremely useful indeed. > 4) Should I just instruct the user on > how to work around the problem? E.G.: Change every occurance of `ln' > and/or `ln -s' to `cp -f' in the Makefile. This is not ideal. By definition, something is still broken if this has to be resorted to - but it is one possible solution (probably should only be used as a last resort). Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: Afr...@bi... |
From: Earnie B. <ear...@ya...> - 2002-02-10 22:33:03
|
Prof Abimbola Olowofoyeku wrote: > > On 10 Feb 2002 at 11:47, Earnie Boyd wrote: > > >3) > > Should the MinGW version of GCC be changed to read the symlink file and > > find the appropriate reference? > > This would be extremely useful indeed. > But that would mean that binutils and possibly other packages would also need a fix as MSYS wouldn't be converting the symlink. Hmm... If the Makefile rule was changed to specify the -o switch it wouldn't be a problem to convert the symlink to the actual file for the input. Possibly what needs to occur then is just a Makefile.in change. For GCC that would be gcc/cp/Make-lang.in and just adding a `-o $@' for the cxxmain.o build makes it work. Now just submit a patch to GCC and let the rest of us enjoy the fruits of your labor. ;) So, the MSYS porting rule will need to be: ------------------------------------------------------------------- / When building an object with GCC and the source file is a symlink, | then you should specify the output file name in the Makefile rule. | This is especially true when the basename for the symlink file is \ different than the basename for the parent file. ------------------------------------------------------------------- Then I don't have to change MSYS at all. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Prof A. O. <Afr...@bi...> - 2002-02-11 19:56:42
|
On 10 Feb 2002 at 17:32, Earnie Boyd wrote: [...] > > > Should the MinGW version of GCC be changed to read the symlink file > > > and find the appropriate reference? > > > > This would be extremely useful indeed. > > > > But that would mean that binutils and possibly other packages would also > need a fix as MSYS wouldn't be converting the symlink. Hmm... If the > Makefile rule was changed to specify the -o switch it wouldn't be a > problem to convert the symlink to the actual file for the input. > Possibly what needs to occur then is just a Makefile.in change. For GCC > that would be gcc/cp/Make-lang.in and just adding a `-o $@' for the > cxxmain.o build makes it work. Now just submit a patch to GCC and let > the rest of us enjoy the fruits of your labor. ;) This, if accepted, would only be added to gcc-3.x. From all indications, it will be a long time before this is of use to Mingw. > So, the MSYS porting rule will need to be: > > ------------------------------------------------------------------- / > When building an object with GCC and the source file is a symlink, | > then you should specify the output file name in the Makefile rule. | > This is especially true when the basename for the symlink file is \ > different than the basename for the parent file. > ------------------------------------------------------------------- > > Then I don't have to change MSYS at all. But wouldn't this just be a gcc-specific workaround? Other packages might also need the workaround. It is the simplest solution of course, and for that reason, it should perhaps be pursued. However, I think an even easier solution might be to write a script that scans a file and changes all occurrences of "ln", "ln -s", "LN=", and LN_S=" to point to "cp -f". One could write a small program to do this, but a script might be better (I wouldn't know how to write such a script). I was able to build successfully gcc by manually making the changes. PS: I ran into some problems with 'configure'; 1. I often get this warning/error when running configure scripts: "checking whether make sets ${MAKE}... ../configure: eval: line 1: unexpected EOF while looking for matching `"' ../configure: eval: line " 2. when trying to build gcc, gmake aborted with an error (it couldn't find 'true'). I copied the 'true' script from Cygwin into msys/1.0/bin/, and this problem went away. It seems that, somehow the built-in 'true' command is not invoked. Anyway, the Cygwin script is very small, and so there is no real problem there - I just thought I should report this. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: Afr...@bi... |
From: Earnie B. <ear...@ya...> - 2002-02-12 12:04:09
|
Prof Abimbola Olowofoyeku wrote: > > On 10 Feb 2002 at 17:32, Earnie Boyd wrote: > > [...] > > > > Should the MinGW version of GCC be changed to read the symlink file > > > > and find the appropriate reference? > > > > > > This would be extremely useful indeed. > > > > > > > But that would mean that binutils and possibly other packages would also > > need a fix as MSYS wouldn't be converting the symlink. Hmm... If the > > Makefile rule was changed to specify the -o switch it wouldn't be a > > problem to convert the symlink to the actual file for the input. > > Possibly what needs to occur then is just a Makefile.in change. For GCC > > that would be gcc/cp/Make-lang.in and just adding a `-o $@' for the > > cxxmain.o build makes it work. Now just submit a patch to GCC and let > > the rest of us enjoy the fruits of your labor. ;) > > This, if accepted, would only be added to gcc-3.x. From all > indications, it will be a long time before this is of use to Mingw. > My guess is that it wouldn't be accepted by gcc and would have to be maintained as a local fork. > > So, the MSYS porting rule will need to be: > > > > ------------------------------------------------------------------- / > > When building an object with GCC and the source file is a symlink, | > > then you should specify the output file name in the Makefile rule. | > > This is especially true when the basename for the symlink file is \ > > different than the basename for the parent file. > > ------------------------------------------------------------------- > > > > Then I don't have to change MSYS at all. > > But wouldn't this just be a gcc-specific workaround? That's what needed worked around. > Other packages might also need the workaround. As they come to light then those speculated other packages can gain rules. Until they come to light those speculated other packages don't exist. > It is the simplest solution of course, and for that reason, it should perhaps be pursued. Yes. > However, I think aneven easier solution might be to write a script that > scans a file and > changes all occurrences of "ln", "ln -s", "LN=", and LN_S=" to point to > "cp -f". One could write a small program to do this, but a script might > be better (I wouldn't know how to write such a script). I was able to > build successfully gcc by manually making the changes. > I think a script named `ln' that'll either execute `_ln' (mv ln.exe _ln.exe) or `cp' based on the equality of the basename of source and destination is what's needed. > PS: I ran into some problems with 'configure'; > > 1. I often get this warning/error when running configure scripts: > "checking whether make sets ${MAKE}... ../configure: eval: line 1: > unexpected EOF while looking for matching `"' > ../configure: eval: line " > What package? Put together a test case. > 2. when trying to build gcc, gmake aborted with an error (it couldn't > find 'true'). I copied the 'true' script from Cygwin into > msys/1.0/bin/, and this problem went away. It seems that, somehow the > built-in 'true' command is not invoked. Anyway, the Cygwin script is > very small, and so there is no real problem there - I just thought I > should report this. > Install the snapshot. Cygwin's true isn't a script it's a binary. Hard and fast rule, don't copy binaries from Cygwin to MSYS. Hard and fast rule, remove from PATH directories that point to other POSIX systems, e.g.: Cygwin. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Prof A. O. <Afr...@bi...> - 2002-03-26 22:34:13
|
Jean le Roux wrote: > >This is a bit of a long one, but quite interesting. > >I think I'm closer to the payne of why autoconf-2.53 and automake-1.5 >does not work for me. > >I've installed ActivePerl on my box (NT4 WS). the environment >reflects that the PATH is set containing c:\Perl\bin (for NT). > >Now I run msys and extract autoconf. I do a ./configure and see that >it finds perl in /c/Perl/bin/perl. when subsequently run "make >install", the files are put in /local That is a default directory. You can install anywhere if you configure with ' --prefix=<my_path>' (e.g., 'configure --prefix=/usr') before calling make install. > (which seems to be identical >to /usr/local, as in you can cd there, but there _is_ _no_ /usr >dir!?!) There is a /usr directory. This is from the msys README file: "/usr - the parent directory of the directory containing the DLL". >I also have to add /local/bin to my /etc/profile before the command >is located (ie before i can go "$ autoconf"). > >Anyway, once i try to run autoconf, it complain that >Automake/Struct.pm cannot be located. The file does exist in >{/usr}/local/share/automake/Automake > >Tracking the problem a bit with a perl-wise friend, we discovered >that the automake script tries to tell Perl to load from >/usr/local/share/automake/Automake. Perl, which does not know about >MSys, cant find this path, It would want it to be >c:\msys\1.0\local\share\automake\Automake. In which case you should configure with 'configure --prefix=/usr/local'. >There. So the problem boils down to this. Can I, and if so how, run >"external" bins under msys, so that the paths get translated >correctly ? By knowing that "/usr" = "the parent directory of the directory containing the DLL". Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: Afr...@bi... |
From: Paul G. <pga...@at...> - 2002-03-27 03:21:26
|
On 26 Mar 2002 at 22:36, Prof Abimbola Olowofoyeku wrote: > Jean le Roux wrote: > > > >This is a bit of a long one, but quite interesting. > > > >I think I'm closer to the payne of why autoconf-2.53 and automake-1.5 > >does not work for me. > > > >I've installed ActivePerl on my box (NT4 WS). the environment > >reflects that the PATH is set containing c:\Perl\bin (for NT). > > > >Now I run msys and extract autoconf. I do a ./configure and see that > >it finds perl in /c/Perl/bin/perl. when subsequently run "make > >install", the files are put in /local > > That is a default directory. You can install anywhere if you configure > with ' --prefix=<my_path>' (e.g., 'configure --prefix=/usr') before > calling make install. > > > (which seems to be identical > >to /usr/local, as in you can cd there, but there _is_ _no_ /usr > >dir!?!) > > There is a /usr directory. This is from the msys README file: > "/usr - the parent directory of the directory containing the DLL".] The directories/files under /usr should be the following: /bin, /doc, /.etc, msys.bat, msys.ico. If you have mingw installed on this tree, it should also be listed in the /usr directory as /mingw. Paul G. |
From: Jean le R. <je...@in...> - 2002-03-27 09:57:37
|
Thanx for all the help so far guys, but I still have pain :( I whacked all the installed stuff and redid from start, this time keeping MinGW in a separate dir thans msys eg /c/MinGW and /c/msys/1.0/ I added the /c/MinGW/bin to my PATH in /etc/profile and gcc -v tell me I'm invoking the mingw gcc. (which is comforting, cause thats the only one I have installed :) Next I ran ./configure on my project. All seems to go ok, except that it says it cant find ANSI C headers (or any other headers for that matter) Also, the configure test for mingw32 environment comes up negative, this does not feel right. How do I check the search priority for gcc? Do I need to add the /c/MinGW/include to my PATH aswell? I did a $ ./configure --includedir=/c/MinGW/include aswell. no change. bye -- Jean le Roux Binary Entropy Catalyst |
From: Prof A. O. <Afr...@bi...> - 2002-02-11 23:23:14
|
On 10 Feb 2002 at 17:32, Earnie Boyd wrote: [...] > Then I don't have to change MSYS at all. So, how does one build an MSYS app? I have looked at the docs and I can't see any reference to this. I want to build 'patch' as an MSYS app, since the Mingw version does not seem to like certain things that the Cygwin version handles quite happily. Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: Afr...@bi... |
From: Earnie B. <ear...@ya...> - 2002-02-12 11:52:24
|
Prof Abimbola Olowofoyeku wrote: > > On 10 Feb 2002 at 17:32, Earnie Boyd wrote: > > [...] > > Then I don't have to change MSYS at all. > > So, how does one build an MSYS app? I have looked at the docs and I > can't see any reference to this. I want to build 'patch' as an MSYS > app, since the Mingw version does not seem to like certain things that > the Cygwin version handles quite happily. > Can you give examples of how the MinGW version doesn't do what you want? The better solution is to port patch to MinGW so that it does the right thing. If you can prove that that can't be done then I would be willing to add patch as a MSYS binary. As for building an MSYS app, I've purposefully made it difficult. Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Earnie B. <ear...@ya...> - 2002-02-10 19:40:11
|
Earnie Boyd wrote: > > I have the following options I'm considering: > > 1) What does autoconfiguration do when ln doesn't exist? That was interesting, configure sees that ln doesn't exists and so assigns variable LN the value of `cp' but then config.status uses `ln -s' anyway. > 2) Should MSYS symlink process copy the file instead of creating the > link when the destination basename and source basename are not equal? Maybe, but it'll be a while before this happens > 3) Should the MinGW version of GCC be changed to read the symlink file > and find the appropriate reference? What do you think about this Danny? > 4) Should I just instruct the user on how to work around the problem? > E.G.: Change every occurance of `ln' and/or `ln -s' to `cp -f' in the > Makefile. > For now, this is what I've chosen. Another option I've just thought of may be to script an ln to do the copy. I'll play with this alternative a bit to see if it's more desirable. The good new is, is that I was able to cd gcc-2.95.3-5 ;# I used the Cygwin source tarball. mkdir bld cd bld ../configure --prefix=/mingw --host=mingw32 --build=mingw32 gmake MAKE=gmake gmake MAKE=gmake install ;# I had to remove the existing /mingw/lib/gcc-lib/ gmake MAKE=gmake clean gmake MAKE=gmake Have fun with it, Earnie. P.S.: See this list for an announcement about a snapshot release. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |