OMNeT++ 4.6b1 is available for testing

[Rudolf Hornig]

Dear OMNeT++ users,

We've just released a test version of OMNeT++ 4.6. Version 4.6 contains an updated compiler toolchain for Windows that resolves previous frequent issues with building the INET Framework. We've also enabled C++11 support in the default compiler flags, so now it is possible to use C++11 features in simulation models.

• MSYS2 and MINGW64 is bundled on Windows
  
• Almost all bundled tools have been updated (GCC 4.9, GDB 7.7, etc.)
  
• make now supports parallel builds on Windows (no more lockups with the -j option)
  
• OMNeT++ and models now build with the -std=c++11 option by default
  
• OMNeT++ can be compiled with the clang compiler on Linux and Mac OS X
  
• OMNeT++ API classes can now be placed in the 'omnetpp' namespace (see configure.user to turn on the namespace - turned off by default)
  
• The IDE is now based on Eclipse 4.4 (Luna), and requires Java 1.7 or later.
  

Please download and test this version and report bugs on: http://bugs.omnetpp.org

The OMNeT++ Team

[Michael Kirsche]

A couple of observations while testing the Windows version...

(1) Error messages right after starting mingwenv.cmd for the first time.

mkdir: cannot change permissions of ‘/dev/shm’: Permission denied
mkdir: cannot change permissions of ‘/dev/mqueue’: Permission denied

Seems to disappear after the second time you start mingwenv.cmd / executed ./configure.

(2) OMNeT bin is not set in the PATH variable

WARNING: 'your PATH does not contain X:/omnetpp-4.6b1/bin!

Is the .bash_profile actually used / sourced by MinGW?
Compilation is not possible without setting the bin path...
Maybe setenv is not executed when starting the mingwenv.cmd ???

(3) You wrote that MinGW64 is bundled, build system and host system type during ./configure is 'i686-pc-mingw32' though. Certain libraries (TCL) seem to be only available in the 32bit release, or maybe I just mixed things there...

Compiling OMNeT and afterwards INET with the -j option works fine so far.

I'll write, if I observe other problems / bugs.

Cheers,
Michael

[Jerzy D]

W dniu środa, 10 września 2014 16:59:25 UTC+2 użytkownik Michael Kirsche napisał:

(2) OMNeT bin is not set in the PATH variable

WARNING: 'your PATH does not contain X:/omnetpp-4.6b1/bin!

Is the .bash_profile actually used / sourced by MinGW?
Compilation is not possible without setting the bin path...
Maybe setenv is not executed when starting the mingwenv.cmd ???

Instead of manually setting of PATH you can type bash -l. It will set proper path to bin directory.

Regards,
Jerzy

[Michael Kirsche]

True, bash -l (or --login) opens a new login bash shell, whereas the .profile (or .bash_profile) file is read.
But this should ideally happen when the mingwenv.cmd is started for the first time, therefore my remark that the bin path is not set when you start the mingwenv for the first time.

Am Donnerstag, 11. September 2014 12:31:51 UTC+2 schrieb Jerzy D:

W dniu środa, 10 września 2014 16:59:25 UTC+2 użytkownik Michael Kirsche napisał:

(2) OMNeT bin is not set in the PATH variable

WARNING: 'your PATH does not contain X:/omnetpp-4.6b1/bin!

Is the .bash_profile actually used / sourced by MinGW?
Compilation is not possible without setting the bin path...
Maybe setenv is not executed when starting the mingwenv.cmd ???

[Doug]

I have installed omnet on my "d:" drive in Windows 7.  For some reason 'configure' fails and says "configure: error: Cannot build Tcl/Tk apps, probably due to misconfigured or missing X11 headers or libs.  Check config.log for more info!"

I briefly looked at config.log and found this:

"conftest.cpp:9:19: fatal error: dlfcn.h: No such file or directory"

also:

"conftest.cpp:9:16: fatal error: tk.h: No such file or directory"

I haven't spent much time trying to track down the problem, but I wanted to mention that I am installing on "d:" drive as opposed to "c:".

Linux version seems ok.

Doug

UPDATE: I tried compiling omnet with it located on "c:" drive -- same result.

[Rudolf Hornig]

On Wednesday, 10 September 2014 16:59:25 UTC+2, Michael Kirsche wrote:

A couple of observations while testing the Windows version...

(1) Error messages right after starting mingwenv.cmd for the first time.

mkdir: cannot change permissions of ‘/dev/shm’: Permission denied
mkdir: cannot change permissions of ‘/dev/mqueue’: Permission denied

Seems to disappear after the second time you start mingwenv.cmd / executed ./configure.

Yes, I'm aware of this. It's from the default profile scripts and we can take care of this. 

 

(2) OMNeT bin is not set in the PATH variable

WARNING: 'your PATH does not contain X:/omnetpp-4.6b1/bin!

Is the .bash_profile actually used / sourced by MinGW?
Compilation is not possible without setting the bin path...
Maybe setenv is not executed when starting the mingwenv.cmd ???

In theory mingwenv shoud source in the setenv. Is this happening only the first time or it's always happening?

 

(3) You wrote that MinGW64 is bundled, build system and host system type during ./configure is 'i686-pc-mingw32' though. Certain libraries (TCL) seem to be only available in the 32bit release, or maybe I just mixed things there...

Actually MINGW64 is the project name of the compiler which has both 32bit and 64bit compiler toolshain. We are bundling the 32bit version only. We don't want to migrate to 64bit compiler yet (on windows). That would require to bundle all the libraries (tcl,tk,xml etc). In both 32bit and 64bit version which may extremely confuse users. If anybody needs the 64bit address space we recommend to use Linux or Mac OS X.

 

Compiling OMNeT and afterwards INET with the -j option works fine so far.

Great :)

 

I'll write, if I observe other problems / bugs.

Keep 'em coming...

Rudolf

[Doug]

It appears that the above errors that I reported before might be a result of trying to compile using 32-bit Windows.

Doug

[chetan vashistth]

Getting similar problem while using it on windows.

[Florian Hagenauer]

Hi,

I am not sure if this is a bug or expected behavior (if so, an
explanation would be nice) but it still exists in OMNeT++ 4.6b1:

For a minimum running example I took the latest txc1.cc and added a
finish() function with only a single line:
EV << __LINE__ << ": Finished!" << ev.isDisabled() << std::endl;

Addtionally I added one line to the handleMessage() function:
EV << __LINE__ << ": handleMessage!" << ev.isDisabled() << std::endl;

If I run this with the Tkenv it prints both lines on the Tkenv module
log. If I run it with the Cmdenv the line from finish() is printed on
the console but the one from handleMessage() is not. Why is this the
case and is this expected?

Best regards,
Florian

--
------------------------------------------------------------------------
Florian Hagenauer MSc

University of Paderborn
Department of Computer Science Raum: F1 319
Fürstenallee 11 Email: hage...@ccs-labs.org
33102 Paderborn, Germany Web: http://ccs-labs.org/~hagenauer/
------------------------------------------------------------------------

On 2014-09-10 12:22, Rudolf Hornig wrote:
> Dear OMNeT++ users,
>
> We've just released a test version of OMNeT++ 4.6. Version 4.6 contains
> an updated compiler toolchain for Windows that resolves previous
> frequent issues with building the INET Framework. We've also enabled
> C++11 support in the default compiler flags, so now it is possible to
> use C++11 features in simulation models.
>

> * MSYS2 and MINGW64 is bundled on Windows
> * Almost all bundled tools have been updated (GCC 4.9, GDB 7.7, etc.)
> * make now supports parallel builds on Windows (no more lockups with
> the -j option)
> * OMNeT++ and models now build with the -std=c++11 option by default
> * OMNeT++ can be compiled with the clang compiler on Linux and Mac OS X
> * OMNeT++ API classes can now be placed in the 'omnetpp' namespace

> (see configure.user to turn on the namespace - turned off by default)

> * The IDE is now based on Eclipse 4.4 (Luna), and requires Java 1.7 or
> later.
>
> Please download
> <http://www.omnetpp.org/omnetpp/cat_view/17-downloads/1-omnet-releases/5-test-versions>

> and test this version and report bugs on: http://bugs.omnetpp.org
> The OMNeT++ Team
>

> --
> You received this message because you are subscribed to the Google
> Groups "omnetpp" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to omnetpp+u...@googlegroups.com
> <mailto:omnetpp+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Michael Kirsche]

Hi Florian,

I don't know what you've expected, but this is the behavior that is correct.

ev.isDisabled()
--> Returns true if the simulation is running in an Express or Express-like mode
    where output from <tt>ev&lt;&lt;</tt> and <tt>ev.printf()</tt> statement is
    not printed or logged anywhere but discarded.

So in your code, you simply print the value of the boolean return, which is, of course, 0 as long as you run it under GUI non-express-mode.
If you run your simulation in the express mode (as it is always done under the command line environment), ev is disabled and messages after EV or ev are not printed at all, thus you don't see any messages on the command line. The ev message inside finish is printed, because finish() is called at the end of the simulation, log outputs are necessary then to show simulation outcomes. The isDisabled flag is checked during simulation runtime, it is ignored after the simulation is finished (thus inside finish()).

Hope this helps.

What are you trying to achieve? Optimizing debug output?

Cheers,
Michael

[Florian Hagenauer]

Hi Michael,

thanks for the answer. It makes it more clear why this happens.

> What are you trying to achieve? Optimizing debug output?

For me personally that is not really consistent behavior of ev. When I
run it in the Tkenv it is not printed to the console after the
simulation concluded, but to the module log.

For example UDP.cc in INET has the following line in the
clearAllSockets() function:
EV << "Clear all sockets\n";
https://github.com/inet-framework/inet/blob/master/src/transport/udp/UDP.cc#L578

When the destructor of UDP is called this is printed to the console very
often (for every module once). If this happens while the simulation is
running nothing is printed to the console.

To make it more clear this is the current behavior:

1. simulation running (in Tkenv): print to module log
2. simulation running (in Cmdenv): does not print at all
3. simulation done (in Tkenv): print to module log
4. simulation done (in Cmdenv): print to console

The last two cases are not consistent, it would make more sense to
either have 3. print to the console or 4. print nothing at all.

Best regards,
Florian

--
------------------------------------------------------------------------
Florian Hagenauer MSc

University of Paderborn
Department of Computer Science Raum: F1 319
Fürstenallee 11 Email: hage...@ccs-labs.org
33102 Paderborn, Germany Web: http://ccs-labs.org/~hagenauer/
------------------------------------------------------------------------

On 2014-09-19 14:05, Michael Kirsche wrote:
> Hi Florian,
>
> I don't know what you've expected, but this is the behavior that is correct.
>
> |
> ev.isDisabled()
> -->Returnstrueifthe simulation isrunning inan ExpressorExpress-like mode

> whereoutput from<tt>ev&lt;&lt;</tt>and<tt>ev.printf()</tt>statement is
> notprinted orlogged anywhere but discarded.

> <javascript:>
> 33102 Paderborn, Germany Web:
> http://ccs-labs.org/~hagenauer/ <http://ccs-labs.org/~hagenauer/>

> > an email to omnetpp+u...@googlegroups.com <javascript:>
> > <mailto:omnetpp+u...@googlegroups.com <javascript:>>.

> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.
>

[Michael Kirsche]

Hi Florian,

I would argue that it is indeed consistent and useful.

The TKEnv / GUI environment should be independent from a console or shell as far as possible. You can distribute simulations ready to run and people would expect outcomes to show up in the module log, especially long-term statistics and final outputs that we usually put into the finish() method or the destructor of a simple module.
If I start a simulation via a shortcut or from within Windows, outputs to the console would probably be lost anyways, that's why the TKEnv should put those information in the module log.

The CMDenv is, on the other hand, used and constructed for fast execution. Printing debug / message output during a simulation run would just confuse a user and isn't appropriate at all. Printing out final statistics on the console afterwards is again useful. You can also configure the CMDEnv to be executed in normal mode and thus let module outputs / message logs be printed on the console or disable them partially.
As simulation outputs / log messages can also be redirected into a file for example and exiting a simulation (CTRL + C) only interrupts the simulation but doesn't destroy the already calculated results, it would be a really bad behavior to not print / flush the log messages onto the console or the file.
Redirecting console output to a file is thus often a good thing and would be rendered useless, if messages inside the finish() / destructor methods wouldn't be printed at all.

If by any chance you still want to disable this functionality, then you can do so by simply changing the code of the CMDenv.
In cmdenv.cc, inside the run() method, there's this code:

    // simulate() should only throw exception if error occurred and
    // finish() should not be called.
    simulate();
    disable_tracing = false;

If you change the last line to something like this:

disable_tracing = opt->expressMode;

then you would have a "consistent" behavior; i.e., that messages are not printed after the simulation ends in case you executed the simulation via express mode.

I hope this clears things up and gives you a good idea, why printing outputs inside the finish()/destructor method should go to the console in the CMDEnv and to the module log in the TKEnv!

Regards,
Michael

[Florian Hagenauer]

Hi Michael,

thank you for the long and detailed answer. I see the reasoning behind
the decisions and the quick fix is very helpful.

Best regards,
Florian

--
------------------------------------------------------------------------
Florian Hagenauer MSc

University of Paderborn
Department of Computer Science Raum: F1 319
Fürstenallee 11 Email: hage...@ccs-labs.org
33102 Paderborn, Germany Web: http://ccs-labs.org/~hagenauer/
------------------------------------------------------------------------

On 2014-09-19 15:57, Michael Kirsche wrote:
> Hi Florian,
>

> disable_tracing =opt->expressMode;

[Michael Kirsche]

Hi Rudolf,

a certain error came up in another thread:

When you create a new OMNeT project, you can choose a name, location, initial contents but that's it, you cannot continue since there are no (C++) project types available.
Creating a project with C++ support works though. So C++ settings / project types / toolchain infos might be missing...

Cheers,
Michael

[Rudolf Hornig]

Will look into this.
http://dev.omnetpp.org/bugs/view.php?id=779

Rudolf

[Doug]

Rudolf -- do you think you will be posting a beta 2 soon?  I'm holding off any more testing with beta 1 until some of the more fundamental things (mentioned in these posts) are worked out.

Thanks,

Doug

[Rudolf Hornig]

Yes, last week I was working on INET integration and I will switch to fixing bugs in the omnetpp repo this week so b2 might be available in a week.

[Rudolf Hornig]

Could you send the configure.log file (zipped and directly to me). I would love to look into it.

[Federico Tramarin]

A serious issue exists in the Mac OS X compilation.

CLANG case

You are right one can compile omnet using clang.

However, in this case I am actually not able to compile INET! It compiles all the files, but at the end it returns a linking problem relative to the << operator.

GCC case

The compilation is fine, as in the previous versions. Both omnet and INET.

However, in this second case, the Eclipse IDE does not respect my choice! If I am using gnu gcc (from homebrew), from the terminal I can get what I expect (make uses g++). Instead, from the IDE the clang is used, since at the end it shows up me an error similar to clang: error..... which hence means clang was run!!!

Actually, in the preference of Eclipse, I see that the system provided entries for the builder point to the /Library/Developer....clang folder, even if I explicitly indicated gcc and g++ in the configure.user.

Please let me know if this is a fault of mine..

Regards

Federico

[Rudolf Hornig]

On Friday, 3 October 2014 11:00:01 UTC+2, Federico Tramarin wrote:

A serious issue exists in the Mac OS X compilation.

CLANG case

You are right one can compile omnet using clang.

However, in this case I am actually not able to compile INET! It compiles all the files, but at the end it returns a linking problem relative to the << operator.

INET was not yet adopted to build ok under clang so INET 2.4 may have issues. On the other hand I have patched both the master and integration branch to be able to compile under clang (admittedly tested only on linux).

GCC case

The compilation is fine, as in the previous versions. Both omnet and INET.

However, in this second case, the Eclipse IDE does not respect my choice! If I am using gnu gcc (from homebrew), from the terminal I can get what I expect (make uses g++). Instead, from the IDE the clang is used, since at the end it shows up me an error similar to clang: error..... which hence means clang was run!!!

No, this cannot be. The IDE just calls the makefile in the src directory and the makefile include the omnetpp_root/Makefile.inc which determines the compiler used. This must be 

 

Actually, in the preference of Eclipse,

I'm not sure what dialog/page is this.

 

I see that the system provided entries for the builder point to the /Library/Developer....clang folder, even if I explicitly indicated gcc and g++ in the configure.user.

Did you actually run ./configure?  (you can check what is the actual compiler used in the Makefile.inc)

Rudolf

[Rudolf Hornig]

For me the build works fine on Win32. Did you use the internal ZIP of Windows? (i.e. extracted from the explorer).

Windows sometimes just forgets to extract some files from the archive... (yes, it happens)

[Federico Tramarin]

Il giorno venerdì 3 ottobre 2014 17:40:04 UTC+2, Rudolf Hornig ha scritto:

On Friday, 3 October 2014 11:00:01 UTC+2, Federico Tramarin wrote:

A serious issue exists in the Mac OS X compilation.

CLANG case

You are right one can compile omnet using clang.

However, in this case I am actually not able to compile INET! It compiles all the files, but at the end it returns a linking problem relative to the << operator.

INET was not yet adopted to build ok under clang so INET 2.4 may have issues. On the other hand I have patched both the master and integration branch to be able to compile under clang (admittedly tested only on linux).

Good to know...

 

GCC case

The compilation is fine, as in the previous versions. Both omnet and INET.

However, in this second case, the Eclipse IDE does not respect my choice! If I am using gnu gcc (from homebrew), from the terminal I can get what I expect (make uses g++). Instead, from the IDE the clang is used, since at the end it shows up me an error similar to clang: error..... which hence means clang was run!!!

No, this cannot be. The IDE just calls the makefile in the src directory and the makefile include the omnetpp_root/Makefile.inc which determines the compiler used. This must be 

 

Actually, in the preference of Eclipse,

I'm not sure what dialog/page is this.

 

I see that the system provided entries for the builder point to the /Library/Developer....clang folder, even if I explicitly indicated gcc and g++ in the configure.user.

Did you actually run ./configure?  (you can check what is the actual compiler used in the Makefile.inc)

Rudolf

Dear Rudolf,

I run ./configure, tried with a recompilation from scratch, etc.

Maybe it is a fault of my system, but the IDE actually compile with clang.

Conversely, the Makefile.inc shows that gnu gcc and g++ are being used.

Also, if I compile from a terminal all are working well, and make V=1 says it 

uses the right compiler.

So this confirm that the problem is in the ide.

[Federico Tramarin]

Dear Rudolf,

I think I have found where the "bug" is. And I think it is a bug that probably manifests only on MAC OSX systems.

Actually, configuring correctly the build system to use the self-installed gnu gcc compilers (installed through ports or homebrew),

both omnet and inet compile flawlessly, and *from a terminal* you are able to operate with your projects.

However, if you work in the IDE, the clang based compilers are used, without respecting the user's configuration.

The problem is that the IDE does not import the correct PATH environment variable!

I think it import the baseline system one, instead of the self configured user one.

In my case the PATH variable contains

PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin:/Users/federico/Applications/omnetpp-4.6b1/bin

while the IDE says my PATH is

/usr/bin:/bin:/usr/sbin:/sbin

I do not know why this happens.

However, manually editing the IDE PATH variable (which the ide sas to import from the system!), and adding the /usr/local/bin location of the gcc executables, the IDE started to work perfectly.

By the way, making the output verbose in the IDE, it respected the gcc and g++ executables I indicated, however, having a wrong path, the IDE actually called those based on clang.

Please let me know if you are able to reproduce this bug.

Cheers,

Federico

[Rudolf Hornig]

Yes, the IDE inherits the PATH setting from the process it was started from.

Did you started the IDE from the terminal (by typing 'omnetpp') or you have started it from an other process (Finder, Dock etc.)

Probably the PATH to /usr/local/bin is configured only in a bash.rc file so it is active ONLY for the terminal, but it is not available for graphical programs.

To configure the path for all apps (graphical and console) you need to check the following:

https://developer.apple.com/legacy/library/qa/qa1067/_index.html

(specifically you hav to create/edit the ~/.MacOSX/environment.plist file)

http://stackoverflow.com/questions/7501678/set-environment-variables-on-mac-os-x-lion

Rudolf