The Persistence of Vision Raytracer (POV-Ray).
This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.
Attached to Project: POV-Ray
Opened by Christoph Lipka - 2012-12-12
Last edited by William F Pokorny - 2016-10-15
Opened by Christoph Lipka - 2012-12-12
Last edited by William F Pokorny - 2016-10-15
FS#262 - sources are being compiled twice on Linux
When running make on Linux, the backend source files (and possibly others?) are apparently compiled twice: first from the .../source/backend/ directory, and another time from the .../source/ directory. As an example, here are the corresponding lines for sphsweep.cpp:
g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source -I../../source/base -I../../unix -I../../vfe -I../../vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strin gs -fno-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep. o `test -f 'shape/sphsweep.cpp' || echo './'`shape/sphsweep.cpp
g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I. ./vfe/unix -pthread -I/usr/include/OpenEXR -pthread -I/usr/include -pipe -Wno-multichar -Wno-write-strings -fno -enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.o `test -f 'backend/shape/sphsweep.cpp' || echo './'`backend/shape/sphsweep.cpp
This is especially annoying on platforms that are rather slow at compiling.
Closed by William F Pokorny
Saturday, 15 October 2016, 18:56 GMT
Reason for closing: Fixed
Additional comments about closing:
Saturday, 15 October 2016, 18:56 GMT
Reason for closing: Fixed
Additional comments about closing:
Closing as duplicate compile issue long
fixed.
Confirmed (at least duplicated on Linux ubuntu 12.10).
(capturing the steps with "make 2>&1 >make.log")
But this is not true for all sources.
vfe/ seems immune
but any subdirectories of source/ get explored twice (source/base, source/backend source/frontend)
The options are identical, the paths are not (change of current directory, and not everything get the `test -f ...` part)
For instance, source/base/image/targa.cpp got either:
Notice that the former substitutes source/backend, source/base and source/frontend with source/ ... it's smelly, or fishy (but probably irrelevant).
The former generates the .o & dependency in source/base/ & source/base/.deps/
The latter generates the .o & dependency in source/ & source/.deps/
The first .o is collected in libbase.a (in source/base)
The second .o is collected in libpovray.a (in source)
And to add insult to infamy, the linker is invoked on both libraries, using them not with -l but as input object files (shortcut for a long list of *.o, with internal resolution per archive ):
Removing from the linking command the intermediate libraries (frontend/backend/base) is fine, as everything is in libpovray.a
It seems the Makefile deeper than source/ are not needed (unless someone want to compile a subpart from the local directory, such as when writing new code).
Or that the recursive-makefile should not go deeper than source/
During investigation I got this warning twice and thought it might be of interest:
povms.cpp:304:3: warning: anonymous type with no linkage used to declare variable ‘<anonymous struct> POVMSStreamOrderTables’ with linkage [enabled by default]
base/povms.cpp:304:3: warning: anonymous type with no linkage used to declare variable ‘<anonymous struct> POVMSStreamOrderTables’ with linkage [enabled by default]
Of interest with respect to what?
I think in the context of this particular issue it just shows what we already know: That the files are indeed compiled twice (once from e.g. the .../source/base directory, and once from the .../source directory).
with respect to what the message is trying to tell us ... but yes indeed it also tells us that they 're compiled twice
Fixed with change #5883
Builds about 40% faster