|Anonymous | Login||2020-07-13 15:31 UTC|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000785||OMNeT++||Installer / Productizing||public||2014-11-14 16:35||2014-11-14 17:17|
|Target Version||Fixed in Version||4.6|
|Summary||0000785: MSYS: incorrect OMNETPP_IMAGE_PATH|
|Description||Report from Doug Hudson:|
OMNeT++ cannot locate its images correctly. It appears that files paths (directory/subdirectory) structure is incorrect.
is being displayed as "Loading images from D:dir0dir1dir2omnet-4.6' followed by a bunch of garbage, followed by '...images: *:0'
|Tags||No tags attached.|
I've narrowed down the problem.
The OMNETPP_IMAGE_PATH variable is being modified by the GCC 4.9.1 preprocessor so that it is incorrect. GCC 4.7.2 which is what is bundled with omnet v4.5 does not have this issue.
Attached you will find a very simple test program that consists of the following files:
1) Makefile.inc which includes only the defined directory paths discovered by configure.
2) Makefile which is a very simple makefile that only 'compiles' or expands the test.cc program using the preprocessor. The output produced by 'make' is the file test.i
3) test.cc - a very simple program that is not even complete -- it just uses the OMNETPP_IMAGE_PATH macro.
What I'm doing is this. I'm setting up the environment just like omnet with Makefiles, but only compiling to the extent of the preprocessor stage.
Here is the output -- Original test.cc file:
std::cout << OMNETPP_IMAGE_PATH << std::endl;
Output for GCC 4.7.2 preprocessor:
std::cout << "./bitmaps;./images;C:/tools/omnetpp-4.6/images" << std::endl;
This is correct -- the define for OMNETPP_IMAGE_PATH is correctly replaced within source code to be compiled.
Output from GCC 4.9.1 preprocessor:
std::cout << ".\bitmaps;.\images;C;C:\tools\omnetpp-4.6\tools\win32\tools\omnetpp-4.6\images" << std::endl;
This is incorrect. I'm at a complete loss as to how some of these paths came about, but they are incorrect, and the preprocessor even flipped the backslashes.
GCC 4.9.1 preprocess is doing something different.
Apparently the problem is not in GCC but the MSYS runtime that modifies program arguments(?) in order to facilitate compilation of *nix programs. See "Posix path conversion"
"For any executable not dependent on msys-1.0.dll, MSYS will convert POSIX paths that are used as arguments to Win32 paths. This page attempts to document the heuristics MSYS uses to decide which arguments are POSIX paths and how they should be converted based on the source of msys_p2w in path.cc."
The page goes on to list the conversion rules.
|The conversion is switched of if an argument starts with /. As a workaround on Windows, the configure script adds /; to the beginning of the image_path. Tkenv then strips away the /; from the beginning if it's present.|
|2014-11-14 16:35||andras||New Issue|
|2014-11-14 16:36||andras||Note Added: 0000939|
|2014-11-14 16:42||andras||Note Added: 0000940|
|2014-11-14 17:17||rhornig||Note Added: 0000941|
|2014-11-14 17:17||rhornig||Status||new => resolved|
|2014-11-14 17:17||rhornig||Fixed in Version||=> 4.6|
|2014-11-14 17:17||rhornig||Resolution||open => fixed|
|2014-11-14 17:17||rhornig||Assigned To||=> rhornig|
|2015-10-12 09:28||ammmar1988||Issue cloned: 0000885|
|Copyright © 2000 - 2020 MantisBT Team|