OMNeT++/OMNEST Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000785OMNeT++Installer / Productizingpublic2014-11-14 16:352014-11-14 17:17
Reporterandras 
Assigned Torhornig 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformWindowsOSOS Version
Product Version4.6b1 
Target VersionFixed in Version4.6 
Summary0000785: MSYS: incorrect OMNETPP_IMAGE_PATH
DescriptionReport from Doug Hudson:

OMNeT++ cannot locate its images correctly. It appears that files paths (directory/subdirectory) structure is incorrect.

For example:
D:\dir0\dir1\dir2\omnet-4.6

is being displayed as "Loading images from D:dir0dir1dir2omnet-4.6' followed by a bunch of garbage, followed by '...images: *:0'

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000939)
andras (administrator)
2014-11-14 16:36

Doug:

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:

int main()
{
   std::cout << OMNETPP_IMAGE_PATH << std::endl;
}

Output for GCC 4.7.2 preprocessor:

int main()
{
   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:

int main()
{
   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.
(0000940)
andras (administrator)
2014-11-14 16:42

from Rudolf:

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"

http://www.mingw.org/wiki/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.
(0000941)
rhornig (administrator)
2014-11-14 17:17

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.

- Issue History
Date Modified Username Field Change
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 - 2019 MantisBT Team
Powered by Mantis Bugtracker