'<!> Class "RadioMedium" not found' when running artery from root directory with symlink(s) in its path about artery HOT 62 CLOSED

@Venturina Forgot to say: Thanks for joining and confirming a working setup with Ubuntu 18.04! By now, I'm really intrigued what the core issue here is (and how bizarre it will turn out to be, if we really get to the bottom of it that is, anyways).

from artery.

Simulations work fine when running everything from the canonical/resolved path. So, at least for our case we have a workaround, though a proper fix is probably needed in OMNeT++. Big thanks again to everyone involved!

from artery.

So, I've done some further investigation regarding my assumption that this has to be related to a root cause within the underlying system and dependencies of the simulation framework, here are my findings so far:

• An upgrade of the affected machine to Ubuntu 18.04 did not solve this.
• We booted an ArchLinux live system on the affected simulation node and within this ArchLinux we were successfully able to run the artery example and our own implementation and scenarios, without running in this issue.
• A (rather brief) look at the ned parser in OMNeT++ shows a dependency to bison, probably flex, m4 and libxml2.
• From these only bison and libxml2 differed in their versions between the ArchLinux and Ubuntu environments.
• Yet, compiling both in their Arch versions on Ubuntu 18.04 (bison in version 3.0.5 and libxml2 in version 2.9.8) and forcing a recompilation of OMNeT++ and whole artery code (incl. INET, etc.) with these exact versions did not yield any changes, i.e., bug is still there.
• We were able to reproduce this bug on another machine with Ubuntu 16.04 and a Intel Xeon E5520.

So, in summary:

• it seems that this bug is not hardware-dependent (at least not specifically to the initally mentioned CPU). I adjusted the title of this issue accordingly.
• we are able to reproduce this with Ubuntu 16.04 and 18.04. ArchLinux and Gentoo distributions seem not to be affected. So, we assume this bug to be somewhere in the diff of artery's and OMNeT++'s/INET's dependencies within these distributions. Yet, I'd expect more users of artery (or even INET/OMNeT++) to be affected by this.

from artery.

On both systems I see

mangledName:  N4inet13physicallayer11RadioMediumE
opp_demangle_typename ret:  inet::physicallayer::RadioMedium

but on the affected system the last two calls to opp_demangle_typename before the exception are:

mangledName:  N7omnetpp7cModuleE
opp_demangle_typename ret:  omnetpp::cModule

mangledName:  N7omnetpp7cModuleE
opp_demangle_typename ret:  omnetpp::cModule

backtrace for the first call to opp_demangle_typename:

#0  omnetpp::opp_demangle_typename (mangledName=<optimized out>) at util.cc:75
#1  0x00007ffff6638ec7 in omnetpp::opp_typename (t=...) at util.cc:207
#2  0x00007ffff63b3618 in omnetpp::cException::storeContext (this=<optimized out>) at cexception.cc:119
#3  0x00007ffff63b2e2b in omnetpp::cException::cException (this=0x6120000573c0) at cexception.cc:46                                                                                  
#4  0x00007ffff63b88e4 in omnetpp::cRuntimeError::cRuntimeError (this=0x6120000573c0, msgformat=0x7ffff69acda0 <.str.3> "Class \"%s\" not found -- perhaps its code was not linked in, or the class wasn't registered with Register_Class(), or in the case of modules and channels, with Define_Module()/Define_Channel()") at cexception.cc:228
#5  0x00007ffff6278031 in omnetpp::cObjectFactory::get (className=0x6180000d3528 "RadioMedium", contextNamespace=<optimized out>, fallbackToOmnetpp=<optimized out>) at cobjectfactory.cc:50
#6  0x00007ffff627830a in omnetpp::cObjectFactory::createOne (classname=0x7ffff6a05520 <typeinfo name for omnetpp::cModule> "N7omnetpp7cModuleE") at cobjectfactory.cc:65            
#7  0x00007ffff62b36f4 in omnetpp::cModuleType::instantiateModuleClass (this=0x61100018a780, className=0x6180000d3528 "RadioMedium") at ccomponenttype.cc:357                        
#8  0x00007ffff62b2179 in omnetpp::cModuleType::create (this=0x61100018a780, moduleName=0x612000007140 "radioMedium", parentModule=0x6110001b4580, vectorSize=-1, index=0) at ccomponenttype.cc:293
#9  0x00007ffff692538e in omnetpp::cNedNetworkBuilder::addSubmodule (this=0x7fffffffd2e0, compoundModule=0x6110001b4580, submod=<optimized out>) at netbuilder/cnednetworkbuilder.cc:763
#10 0x00007ffff6924340 in omnetpp::cNedNetworkBuilder::addSubmodulesAndConnections (this=0x7fffffffd2e0, modp=0x6110001b4580) at netbuilder/cnednetworkbuilder.cc:474                
#11 0x00007ffff6923322 in omnetpp::cNedNetworkBuilder::buildInside (this=0x7fffffffd2e0, modp=<optimized out>, decl=0x618000038880) at netbuilder/cnednetworkbuilder.cc:443          
#12 0x00007ffff6918d4c in omnetpp::cDynamicModuleType::buildInside (this=<optimized out>, module=0x6110001b4580) at netbuilder/cdynamicmoduletype.cc:89                              
#13 0x00007ffff648c624 in omnetpp::cModule::buildInside (this=<optimized out>) at cmodule.cc:1176                                                                                    
#14 0x00007ffff6583d5b in omnetpp::cSimulation::setupNetwork (this=0x60f000001e40, network=<optimized out>) at csimulation.cc:388                                                    
#15 0x00007ffff75718f7 in omnetpp::envir::EnvirBase::setupNetwork (this=0x617000002a80, network=0x61100010fd00) at envirbase.cc:766                                                  
#16 0x00007ffff7ba2f90 in omnetpp::cmdenv::Cmdenv::doRun (this=0x617000002a80) at cmdenv.cc:243                                                                                      
#17 0x00007ffff7571309 in omnetpp::envir::EnvirBase::run (this=0x617000002a80) at envirbase.cc:742                                                                                   
#18 0x00007ffff7562848 in omnetpp::envir::EnvirBase::run (this=0x617000002a80, argc=16, argv=0x7fffffffe178, configobject=0x615000002600) at envirbase.cc:354                        
#19 0x00007ffff7549299 in omnetpp::envir::setupUserInterface (argc=16, argv=0x7fffffffe178) at startup.cc:259                                                                        
#20 0x00007ffff754c700 in evMain (argc=-157264608, argv=0x9ddfea08eb382d69) at evmain.cc:33                                                                                          
#21 0x00007ffff2b89b97 in __libc_start_main (main=0x516e70 <main(int, char**)>, argc=16, argv=0x7fffffffe178, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe168) at ../csu/libc-start.c:310
#22 0x000000000041a61a in _start ()

from artery.

So, the culprit is using the /ibr symlink.

13548:Finding package property: namespace for type inet.physicallayer.common.packetlevel.RadioMedium
13549:Visiting NED file: /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
13550:getParentPackage for /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
13551-absPath: /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel
13552-folderName: /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel
13553-folderPackage.f: /ibr/projects/artery-lte/artery_hagau/extern/inet/src
13554-folderPackage.s:
13555-isPathPrefixOf: comparing: /ibr/projects/artery-lte/artery_hagau/extern/inet/src  and   /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/pac
ketlevel
13556-isPathPrefixOf:2 not prefix

It works if I use the full path.

from artery.

@torokati44 Thanks for the pointer to look at the filesystem, I would not have checked again otherwise :)

from artery.

@torokati44 Thank you very much for your help! We'll finish this next week :)

from artery.

Well, isn't the problem that the symlink is resolved somewhere, even though it shouldn't be?

I mean, the goal is consistency, but we should clarify first whether we should have resolved or unresolved path names everywhere. My vote is on unresolved, since what symlinks you have on your system on the path leading to OMNeT++ should not be relevant - especially not where they point.

And I don't think OMNeT++ at the moment manually tries to resolve symlinks, neither do I think it should. (It only converts relative paths to absolute ones, and deals with . and ...)
The only thing I can think of is that some filesystem/path manipulation function we use resolves them anyway, and maybe we should prevent that?

from artery.

You are right, getcwd is the offending call

5264:getting file: RadioMedium.ned NOT FOUND                                                                                                                                         
5265:toAbsolutePath:pathname RadioMedium.ned                                                                                                                                         
5266:toAbsolutePath:ret /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned                                             
5267:added file /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned using key /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned

In this case the getcwd in toAbsolutePath is called and expands the symlink.
(The man page doesn't mention it, but http://pubs.opengroup.org/onlinepubs/9699919799/functions/getcwd.html does)

from artery.

A big thank you, @torokati44 and @hagau, for your thorough investigation of this issue. I just changed the title of this issue to reflect the current state of our knowledge. Moreover, I'm just testing whether we can just build and run everything from the canonical/resolved path as workaround for now.

from artery.

We created an entry for this in the OMNeT++ bug tracker:
https://dev.omnetpp.org/bugs/view.php?id=1051

from artery.

trace with debug symbols

#0  omnetpp::cRuntimeError::notifyEnvir (this=0x15144c0) at cexception.cc:260
#1  0x00007ffff7378a7c in omnetpp::cRuntimeError::cRuntimeError (this=0x15144c0, 
    msgformat=0x7ffff74d19f8 "Class \"%s\" not found -- perhaps its code was not linked in, or the class wasn't registered with Register_Class(), or in the case of modules and channels, with Define_Module()/Define_Channel()") at cexception.cc:234
#2  0x00007ffff73261be in omnetpp::cObjectFactory::get (className=0x14b4668 "RadioMedium", contextNamespace=0x0, fallbackToOmnetpp=true) at cobjectfactory.cc:52
#3  0x00007ffff73262c0 in omnetpp::cObjectFactory::createOne (classname=0x14b4668 "RadioMedium") at cobjectfactory.cc:65
#4  0x00007ffff733683f in omnetpp::cModuleType::instantiateModuleClass (this=0x14b4a60, className=0x14b4668 "RadioMedium") at ccomponenttype.cc:357
#5  0x00007ffff74af393 in omnetpp::cDynamicModuleType::createModuleObject (this=0x14b4a60) at netbuilder/cdynamicmoduletype.cc:66
#6  0x00007ffff73364c7 in omnetpp::cModuleType::create (this=0x14b4a60, moduleName=0x7d27b0 "radioMedium", parentModule=0x1513340, vectorSize=-1, index=0) at ccomponenttype.cc:293
#7  0x00007ffff733631f in omnetpp::cModuleType::create (this=0x14b4a60, moduleName=0x7d27b0 "radioMedium", parentModule=0x1513340) at ccomponenttype.cc:265
#8  0x00007ffff74b3f00 in omnetpp::cNedNetworkBuilder::addSubmodule (this=0x7fffffffd8f0, compoundModule=0x1513340, submod=0x7d2730) at netbuilder/cnednetworkbuilder.cc:763
#9  0x00007ffff74b2059 in omnetpp::cNedNetworkBuilder::addSubmodulesAndConnections (this=0x7fffffffd8f0, modp=0x1513340) at netbuilder/cnednetworkbuilder.cc:474
#10 0x00007ffff74b1ff1 in omnetpp::cNedNetworkBuilder::buildRecursively (this=0x7fffffffd8f0, modp=0x1513340, decl=0x13489e0) at netbuilder/cnednetworkbuilder.cc:466
#11 0x00007ffff74b1e66 in omnetpp::cNedNetworkBuilder::buildInside (this=0x7fffffffd8f0, modp=0x1513340, decl=0x13489e0) at netbuilder/cnednetworkbuilder.cc:443
#12 0x00007ffff74af5ab in omnetpp::cDynamicModuleType::buildInside (this=0x1349090, module=0x1513340) at netbuilder/cdynamicmoduletype.cc:89
#13 0x00007ffff73a1975 in omnetpp::cModule::doBuildInside (this=0x1513340) at cmodule.cc:1187
#14 0x00007ffff73a18b0 in omnetpp::cModule::buildInside (this=0x1513340) at cmodule.cc:1176
#15 0x00007ffff73d8c12 in omnetpp::cSimulation::setupNetwork (this=0x67c480, network=0x1349090) at csimulation.cc:388
#16 0x00007ffff78f44c9 in omnetpp::envir::EnvirBase::setupNetwork (this=0x78b5c0, network=0x1349090) at envirbase.cc:766
#17 0x00007ffff7bcd9b6 in omnetpp::cmdenv::Cmdenv::doRun (this=0x78b5c0) at cmdenv.cc:243
#18 0x00007ffff78f4374 in omnetpp::envir::EnvirBase::run (this=0x78b5c0) at envirbase.cc:742
#19 0x00007ffff78f1dce in omnetpp::envir::EnvirBase::run (this=0x78b5c0, argc=16, argv=0x7fffffffe208, configobject=0x683850) at envirbase.cc:354
#20 0x00007ffff78ea1ee in omnetpp::envir::setupUserInterface (argc=16, argv=0x7fffffffe208) at startup.cc:259
#21 0x00007ffff78eb6ee in omnetpp::envir::evMain (argc=16, argv=0x7fffffffe208) at evmain.cc:33
#22 0x0000000000400796 in main (argc=16, argv=0x7fffffffe208) at main.cc:31

from artery.

I'd like to note that there is a inet::physicallayer::RadioMedium in the global classes registry before the exception.
A classes.getInstance()->lookup("RadioMedium", "inet::physicallayer", true) returns the desired omnetpp::cObjectFactory.

from artery.

As reference, on my system omnetpp::cModuleType::instantiateModuleClass gets called with className=inet::physicallayer::RadioMedium.
The className comes from implClassName of the omnetpp::cNedDeclaration of inet.physicallayer.ieee80211.packetlevel.Ieee80211ScalarRadioMedium, which should be inet::physicallayer::RadioMedium, but is RadioMedium on the afflicted system.

So this is some sort of parsing issue in the NED parser maybe?

from artery.

Further observations:

• fixing the namespace of the className argument in gdb works
• after RadioMedium, some other modules are added correctly until ConstantSpeedPropagation, after which every className is missing its proper namespace.

For some reason, the implClassName of the omnetpp::cNedDeclaration for some classes is not namespaced properly.

from artery.

We came across an issue recently that likely shares a root cause with this one. See the fix for that here: inet-framework/inet@bfa3712

In a scenario where a module type in a project extends a module type in another project (say, Artery and INET), but only on the NED level, without its own custom C++ class, the class name lookup can fail.
In this case, the @class property of the supertype (which is in a namespace) is inherited by the subtype - in a different namespace.

If the supertype does not specify the namespace of the class inline (like @class(inet::physicallayer::RadioMedium)), but instead relies on the preceding standalone namespace statements (like INET does), then the class will be searched for in the namespace of the subtype (like artery).

To work around this, you could add explicit overrides to any such subtype with fully qualified class names: @class(inet::physicallayer::RadioMedium)

However, we are not aware of anything that would make this hardware- or OS-dependent. Are you absolutely sure that the exact same revisions of all the numerous components are running in the working and non-working cases? It might just be that this corner case was only introduced in a recent revision of one of the projects.

If my description was not clear, feel free to ask for more details.

from artery.

Thank you for your very thorough explanation, @torokati44! It reads to me as if this could be the root cause, but this has to be checked, of course. We will see to try the mentioned possibilities for a fix. Thanks!

As to your question regarding hardware- or OS-dependencies: I, too, was a bit reluctant to attribute this error that we are seeing to the hardware or OS, as I am not aware of, e.g., any parallelism that would allow for such a dependency.

However, we were and are testing this with the exact same revision (i.e., branch/commit hash) of artery (and subsequently its bundled INET revision) as well as the exact same OMNeT++ version(s) (as described we tested 5.4 and 5.4.1). We also eliminated different compilers as possible cause. Yet, we still have the simulations working on two developer machines which after checking all these things only differ in Linux distribution and hardware (or sth. we are currently overlooking).

from artery.

@torokati44 Thank you, that makes sense to me.

Hm, we do not subtype inet::physicallayer::RadioMedium here:

from artery.

I see. Well that's strange. Does the NEDPATH (-n option) contain the src directory of INET in both cases? Does the package.ned file in src/inet contain @namespace(inet);? Are there any other @namespace(...); directives anywhere else in the INET source tree, in any .ned file?

EDIT: Corrected mistakes...

from artery.

• NEDPATH contains INET root
• src/inet/package.ned does contain @namespace(inet)
• there are @namespace(...) directives in src/inet/ but they all make sense, e.g.
  src/inet/physicallayer/package.ned has @namespace(inet::physicallayer)

from artery.

Just a random idea: What if you change the NEDPATH to contain either the src directory of INET, or src/inet? Does it make a difference having one or the other?

from artery.

src or src/inet make no difference, still the same issue.

from artery.

I'm using the same script to launch the simulation on both systems, the afflicted one and my development system (where everything works perfectly)
EDIT: so the NEDPATH should be correct

from artery.

We'll look into it a bit more tomorrow.

from artery.

@torokati44 Thanks, and thank you for the quick reply!

from artery.

We did not forget about this, we just have to prepare for the annual Community Summit.
We have to postpone this for about a week, sorry.

from artery.

@m-wegner Can you try to build Artery on Ubuntu with another compiler, i.e. one that has not been "improved" by Ubuntu? I had already quite some fun with Ubuntu's specific compiler tuning…

from artery.

@riebl Yeah, I think, we could try upstream clang, I've done this before with Ubuntu. As I have to run this by our admin, this will have to wait till tomorrow, though (I'd like to just use LLVM's PPA, and not set clang up myself). 😉 But thanks for the suggestion! We'll try that.

from artery.

Could you try to print the mangledName parameter of opp_demangle_typename (in src/sim/util.cc), as it is passed in?
Also, the return value? - This might be the easiest to print from opp_typename (as this is the only place where opp_demangle_typename is called from).
Is there any difference in these between the affected and unaffected setups?

from artery.

@m-wegner Just as a note: I'm using Ubuntu 18.04 and I have tried to reproduce your error, but I'm not experiencing any error when running the Artery example scenario.
Do I have to change anything in the scenario to reproduce it?

from artery.

@Venturina No, this should be reproducible with a clean checkout.

from artery.

Do I have to change anything in the scenario to reproduce it?

@Venturina No, we used plain OMNeT++ 5.4 or 5.4.1, respectively (compiled without osg, osgearth and qtenv/tkenv support). Artery built according to README and we launched the scenario as stated in the initial comment in this issue: We just changed the command line to run the Cmdenv of OMNeT++ and chose the envmod config section of scenarios/artery/omnetpp.ini.

from artery.

@torokati44 Thanks for your suggestion, we'll try that as well (probably also by tomorrow) and will report back with the results.

from artery.

Thanks!

Could you now try replacing the NedTypeInfo::getPackageProperty method in src/nedxml/nedtypeinfo.cc with this annotated version?

std::string NedTypeInfo::getPackageProperty(const char *propertyName) const
{
    std::cout << "Finding package property: " << propertyName << " for type " << this->getFullName() << std::endl;

    // find first such property in the current file, then in package.ned of this package and parent packages
    for (NedFileElement *nedFile = (NedFileElement *)getTree()->getParentWithTag(NED_NED_FILE);
         nedFile != nullptr;
         nedFile = getResolver()->getParentPackageNedFile(nedFile))
    {
        std::cout << "Visiting NED file: " << nedFile->getFilename() << std::endl;
        const char *propertyValue = ASTNodeUtil::getLocalStringProperty(nedFile, propertyName);
        if (propertyValue) {
            std::cout << "returning: " << propertyValue << std::endl;
            return propertyValue;
        }
    }
    std::cout << "returning: EMPTY" << std::endl;
    return "";
}

... and posting what it prints in both cases?

from artery.

On the working setup:

Finding package property: namespace for type inet.physicallayer.common.packetlevel.RadioMedium
Visiting NED file: /{...}/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
Visiting NED file: /{...}/artery/extern/inet/src/inet/physicallayer/package.ned
returning: inet::physicallayer

on the affected system:

Finding package property: namespace for type inet.physicallayer.common.packetlevel.RadioMedium                                                                                  
Visiting NED file: /{...}/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned                                             
returning: EMPTY

from artery.

It always returns "" from NedTypeInfo::getPackageProperty on the affected system and never finds the parent package.ned...

from artery.

And I presume there is a {...}/artery/extern/inet/src/inet/physicallayer/package.ned file on both systems, with identical contents...

Are the filesystems the same type? Are the file permissions different? Any uppercase/lowercase differences, or case sensitivity differences? (Probably all of them are the same, but just in case...)

How about if you add the cout line to NedResourceCache::addFile in this place:

    NedFileMap::iterator it = files.find(key);
    if (it != files.end())
        return false;  // already added

    std::cout << "added file " << fname << " using key " << key << std::endl; // add this line

    files[key] = node;

from artery.

On my working Ubuntu 18.04 I'm also using omnet 5.4.1 without osg and osgearth and tkenv (so the build differs only at the qtenv option). I'm also starting the scenario using your script.

I'm not sure if it is helping you, but I have tried the same steps to verify my setup.

Changing the NedTypeInfo::getPackagePropertyoutputs the same as yours on the working setups.

Finding package property: namespace for type inet.physicallayer.common.packetlevel.RadioMedium
Visiting NED file: /path/to/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
Visiting NED file: /path/to/artery/extern/inet/src/inet/physicallayer/package.ned
returning: inet::physicallayer

Adding the above mentioned cout line prints the following regarding the RadioMedium.ned

added file path/to/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned using key /path/to/artery/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned

from artery.

• Yes, the file exist & has the correct spelling and permissions
• Well, on the affected system it's a NFS mounted ZFS. Should not be a problem, I think.
  NedResourceCache::addFile

The addition to NedResourceCache::addFile produces:

added file {...}/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned using key {...}/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned                                                                                                                

from artery.

@Venturina Thanks for verifying!

from artery.

Thanks! The question is, does it also add the package.ned file in the .../inet/src/inet/physicallayer/ folder?
Also, if you don't mind, what is the actual full path and key for these files - without replacing it with {...}?

from artery.

Full path is:

added file /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned using key /misc/ibr/projects/artery-lte/artery_hagau/
extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned

from artery.

package.ned is also added:

added file /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/package.ned using key /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/ph
ysicallayer/package.ned

from artery.

Thank you so much for the quick responses. We are clueless so far. We'll get back to this tomorrow. :)

from artery.

@torokati44 Thank you for your help! :)

from artery.

If you replace these two functions in nedresourcecache.cc with these annotated versions:
https://gist.github.com/torokati44/b644f08758d5f4cff3dffd3e8f7ad9f0

Where do they diverge?

from artery.

On the affected system:

Finding package property: namespace for type inet.physicallayer.common.packetlevel.RadioMedium              
Visiting NED file: /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned                                              
getParentPackage for /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned                                            
topDir:
returning: EMPTY

from artery.

I've butterfingered the make on my working setup, so that will take a bit of time, since recompile :)

But I noticed something on the affected system:

8158:Finding package property: namespace for type inet.physicallayer.common.packetlevel.RadioMedium
8159:Visiting NED file: /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
8160:getParentPackage for /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
8161-absPath: /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel
8162-folderName: /misc/ibr/projects/artery-lte/artery_hagau/extern/inet/src/inet/physicallayer/common/packetlevel
8163-folderPackage: /ibr/projects/artery-lte/artery_hagau/extern/inet/src
8164-folderPackage: /ibr/projects/artery-lte/artery_hagau/extern/veins/examples/veins
8165-folderPackage: /ibr/projects/artery-lte/artery_hagau/extern/veins/src/veins
8166-folderPackage: /ibr/projects/artery-lte/artery_hagau/src/artery
8167-folderPackage: /ibr/projects/artery-lte/artery_hagau/src/traci
8168-topDir:
8169-returning: EMPTY

Nope, there's a symlink from /ibr -> /misc/ibr ...

from artery.

On my working setup, as expected:

Finding package property: namespace for type inet.physicallayer.common.packetlevel.RadioMedium
Visiting NED file: /home/artery/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
getParentPackage for /home/artery/artery/extern/inet/src/inet/physicallayer/common/packetlevel/RadioMedium.ned
topDir: /home/artery/artery/extern/inet/src

from artery.

So, at some point, the symlink gets resolved, and this causes some mismatches down the line? Between the unresolved and resolved paths?

from artery.

No, the symlink not getting resolved is the problem. For some reason, folderPackages in nedresourcecache.cc gets initialized with the unresolved path. I'm still investigating the root cause...

from artery.

Well, there are a couple getcwd calls in toAbsolutePath. I'm not sure if that consistently returns either a resolved or an unresolved path.

from artery.

Hm, the getcwd isn't reached in this case, since the path starts with a /.

from artery.

Even the paths that are passed in as $NEDPATH or the -n option?
If they are absolute, do they go through the symlink or not?

from artery.

Yes, I'm passing full, unresolved paths in $NEDPATH/-n and they go through the symlink.

from artery.

But then where do any paths that don't go through the symlink come from?

from artery.

I don't know :)
$OMNETPP_HOME is also set to /ibr/..., and this works when I set the $NEDPATH to the resolved path.

from artery.

In NedResourceCache::loadNedSourceFolder, should not the canonicalFolderName be the resolved pathname? I've got /ibr/.. on the affected system.

from artery.

Seems like OMNeT++ should use something like readlink(2) or realpath(3) to canonicalize all paths, thereby resolving any ambiguity due to symlinks for any parameters and read file paths.

from artery.

Needs to be solved in OMNeT++, see bug tracker entry. Closing.

from artery.

I have not been able to solve this error for a long time, I need help.
Class "inet::physicallayer::RadioMedium" not found -- perhaps its code was not linked in, or the class wasn't registered with Register_Class(), or in the case of modules and channels, with Define_Module()/Define_Channel() -- in module (omnetpp::cModule) Scenario (id=1), during network setup

from artery.

Please create a new issue ticket for your problem instead of hijacking issue tickets closed years ago.

By the way, the actual reason why your setup fails is usually printed before the *Class "inet::physicallayer::RadioMedium" not found" error message. Look out for "undefined symbol" messages.

from artery.