| msg70998 - (view) |
Author: Skip Montanaro (skip.montanaro) *  |
Date: 2008-08-11 00:55 |
| I usually build Python directly in my source repository (the directory containing the configure script). Accordingly, I have .o files scattered throughout my sandbox. Today I decided to build --with-pydebug, so I created a debug directory, then ran ../configure from within that directory, giving the arguments I wanted. When I ran make it croaked with a link error linking pgen. The linker complained that tokenizer_pgen.o and pgenmain.o weren't found. Messing around with make -d I figured out that when make ran it concluded that Parser/pgenmain.o didn't need to be rebuilt. It thought that ../Parser/pgenmain.o satisfied the dependency for Parser/pgenmain.o. I don't know if this is a problem with GNU make's VPATH processing or with the dependency specification in Python's makefile. I can work around the problem by avoiding builds directly in my sandbox but it would be nice if this worked. (I'm experiencing a sense of deja vu. Perhaps I've reported this problem sometime in the dim, dark past, but I can't find anything searching for either "VPATH" or "makefile".) |
|
|
| msg113254 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-08-08 12:38 |
| I'll close this unless anyone shows some interest in it. |
|
|
| msg113262 - (view) |
Author: Stefan Krah (skrah) *  |
Date: 2010-08-08 13:43 |
| Mark, the proper way of closing an issue is to test first if the problem still exists. |
|
|
| msg113284 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-08-08 17:07 |
| Fascinating, three days from the second birthday, the OP isn't interested, nobody else is interested but it can't be closed. Clearly I'm missing something. Shall we leave this issue until it gets to it's 10th birthday? |
|
|
| msg113286 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2010-08-08 17:10 |
| Yes, if it's still a problem. |
|
|
| msg113290 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-08-08 17:48 |
| Mark, instead of using sarcasm, it would be more productive to research this bug. Skip has given a hint that the search terms "VPATH" or "Makefile" might be relevant. Searching for "VPATH" immediately yields issue 1613, which looks very similar: gcc: Parser/pgenmain.o: No such file or directory Why don't you try to find out if they are related? It is an excellent opportunity to get acquainted with the Python build process. |
|
|
| msg113294 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2010-08-08 18:12 |
| Stefan, I'm not interested in researching something that has been available for others to research for two years, I don't understand why they aren't interested and I don't care. If noone can be bothered with an issue why leave it to rot, why not simply close it? Why is this issue different to others that I have set to pending and then after a couple of weeks closed without having a single comment back? |
|
|
| msg113295 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2010-08-08 18:14 |
| 2010/8/8 Mark Lawrence <report@bugs.python.org>: > > Mark Lawrence <breamoreboy@yahoo.co.uk> added the comment: > > Stefan, I'm not interested in researching something that has been available for others to research for two years, I don't understand why they aren't interested and I don't care. If noone can be bothered with an issue why leave it to rot, why not simply close it? Why is this issue different to others that I have set to pending and then after a couple of weeks closed without having a single comment back? It's not different from others. Bugs should stay open until they are resolved in some way. Closing a bug for lack of input is only acceptable when the information needed is to clarify the problem from the OP. |
|
|
| msg113305 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2010-08-08 20:03 |
| If VPATH is intended to work without doing `make distclean` first in the root directory, then this is still valid. I'm not sure if this is the case though (see also issue 1613). cd py3k/ ./configure --with-pydebug make mkdir debug cd debug/ ../configure --with-pydebug make ... gcc: Parser/tokenizer_pgen.o: No such file or directory gcc: Parser/printgrammar.o: No such file or directory gcc: Parser/pgenmain.o: No such file or directory make: *** [Parser/pgen] Error 1 cd ../ make distclean cd debug/ make # (works now) |
|
|
| msg218551 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2014-05-14 15:58 |
| The original problem is fixed, but a similar one exists with testembed (see for instructions): gcc -pthread -Xlinker -export-dynamic -o Modules/_testembed Modules/_testembed.o libpython3.5dm.a -lpthread -ldl -lutil -lm gcc: error: Modules/_testembed.o: No such file or directory make: *** [Modules/_testembed] Error 1 |
|
|
| msg261884 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2016-03-17 04:32 |
| The fault still exists for me with the pgen objects. The makefile has changed a few times about automatically compiling pgen (Issue 22359) or not (Issue 14321), so it would depend which version is tested. I’m not an expert on VPATH, but it seems like it would be a awkward working around this problem (e.g. adding absolute paths do all the object file names or something). I propose to just close this. Issue 1613 added a note to the Python 2 README, and Python 3’s README says: [Building from a subdirectory] will fail if you *also* built at the top-level directory. You should do a "make clean" at the toplevel first. |
|
|
| msg413925 - (view) |
Author: Irit Katriel (iritkatriel) * |
Date: 2022-02-24 16:13 |
| Closing as suggested by Martin. |
|
|