Hi folks,

            In view of the recent posts re: path translation, it seemed appropriate to write a follow up in the offhand hope that it might facilitate a better understanding of the limitations of "make".

On 22 Aug 2002 at 3:28, Paul G. wrote:

> Hi folks,
>  Thanks for your time and for checking.
>   Problem solved.
>    Paul G.
> On 22 Aug 2002 at 2:45, Paul G. wrote:
> > Working on port of Python 2.2.1.
> >
> > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes  Parser/acceler.o
> > Parser/grammar1.o  Parser/listnode.o Parser/node.o Parser/parser.o
> > Parser/parsetok.o Parser/tokenizer.o  Parser/bitset.o
> > Parser/metagrammar.o Python/mysnprintf.o Parser/firstsets.o
> > Parser/grammar.o Parser/pgen.o Parser/printgrammar.o
> > Parser/pgenmain.o /usr/lib  -o  Parser/pgen.exe
> > d:\msys\1.0\mingw\bin\..\lib\gcc-lib\mingw32\2.95.3-6\..\.. \..\..\mi
> > ng w32\bin\ld.exe:  cannot open d:\msys\1.0\lib: Permission denied
> > make: *** [Parser/pgen.exe] Error 1

            The error was caused when make tried to read /usr/lib.  I think I managed to confuse it (it being "ld.exe") into thinking that /usr/lib should have been treated as an ld switch setting of -l/usr/lib or, after translation (with -l added), -l"/usr/lib" or "- l/usr/lib" to the ld.exe command line.

            Of course that will fail, as it is not a valid library reference.  Still, was surprised that ld even "tried" to deal with it in the first place. (autoconfig limitation? maybe...?)

            No matter.  After removing the offending "/usr/lib", that portion of the build (the "link and generation of pgen.exe" via ld) worked just fine.  (Checked it manually as well.)

            The rest of the things that came up for me had to do with the "Python port" (OT) and pulling it together, so will not mention them here.

            Paul G.