MPS error when rebuilding projects: "no output location for x#descriptor" - mps

I am new to JetBrains MPS and am trying to get a feel for Jetbrains MPS applications that others have built. However, I am finding that I am unable to build most applications I download from GitHub. Mostly, I get errors when trying to rebuild the project. One common error I get is:
no output location for x#descriptor
...
Error executing target jetbrains.mps.make.facets.Make.reconcile : no input. Stopping
where x is the name of the language.
what must I update to fix it?
Extra Details:
OS: Windows 10
MPS: 2020.2
example git repo: https://github.com/DSLFoundry/mps-examples/Sorting

Another cause could be that for some reason the Java Facet has not been enabled. AFAIK between 2020.1 and 2020.3 (haven't checked 2020.2) this has become necessary for some/most languages.
The easy fix is to enable the Java Facet in the Module properties for the Language/Generator which reports "No output location for.../behaviour" etc.

Related

wxWidgets fails to build due to missing wxxml.lib

Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.
The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.

LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in

I have been using a graphics library from Smaller Animals Software called ImgSource. Unfortunately, Smaller Animals Software has closed and is no longer available to answer questions. Recently, I had a system failure that deleted my only up-to-date copy of the library (I thought I had a backup but was wrong). I did, however, have the source code. I recompiled the library, both release and debug. (Both are static .lib files) I am also using MSVS 2019 Community edition and the project is an MFC project. The problem, and why I'm posting here, is that when I link the new release library with a previous project, the project compiles properly. However, when I build the debug version, it will compile, but not link and produces the linker error discussed LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in file.obj
A reasonable conclusion is that there is something wrong with the debug library. However, if I build a new project and link the debug library, everything works fine. So, the error does not appear to be in the library. It seems I could start from scratch and completely redo these projects, but they do reflect a tremendous amount of work.
I can't figure out how to modify the settings in the existing projects so that they will compile in debug mode. I have tried the suggestions offered in the article referenced above. Further suggestions would be greatly appreciated.

How to make gnuhawk component AudioSink load to redhawk?

Running CentOS 6.5 and RedHawk 1.9.0, and I have audio-components installed in $SDRROOT, and AudioSink shows up in palette, all good. However when I double click to launch it I get the error:
Launching component AudioSink_1 has encountered a problem
and
Failed to launch: AudioSink_1.
When I click on details I get:
Failed to launch: AudioSink_1
and
IDL:CF/ExecutableDevice/ExecuteFail:1.0
Not very informative. Components AudioSource and AudioTestSource also do not launch.
I was having a very similar issue to what you described when I was trying to use Axios-Engineering's RTLTcpSource component. What the issue was for me was I was installing the component incorrectly. So for me this is how I installed a component in REDHAWK.
Download the original source code. (unzip if necessary)
Open the REDHAWK IDE(eclipse)
File->Import...->Existing Projects into Workspace->next->select the source code folder->Finish
Project->Build Project
Drag project folder to "Target SDR" in the SCA Explorer
I hope this helps you or anyone else. I know there aren't really many places that tell you how to actually add an external component to REDHAWK and it took me a while to figure out to just treat it like a normal custom component.
I had a similar problem when using audiosink. The answer above by JD will work but make sure you re-gen the component since the code was made in 1.84 and there is a new codegen for 1.9.
It may also throw a message saying there are errors when exporting to the target SDR but that can mostly be ignored from my experience.
Similarly if you want more of an output, you can run the component/device through the terminal sandbox after building it and set "-Debug 4" to get more information.
Good luck!
edit: seems like a bug with audiosink was addressed: AudioSink unknown error
you might want to just pull down the updated version and try that!

fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL

I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny

Failure to register .dll with regsvr32 - only in Release build

I'm having a weird problem when trying to register the .dll i created using regsvr32.
During development everything went fine, the debug version registers and works fine. Now i wanted to create a Release version, but that Version does not register anymore.
regsvr32 comes up with the following error:
The module "mpegsplitter.dll" failed to load.
Make sure the binary is stored at the specified path or
debug it to check for problems with the binary or
dependent .DLL files.
The specified procedure could not be found.
Some research brought me to the dependency walker, which does tell me this
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
It also does show a dependency on "crtdll.dll" that the debug version does not have (The function view shows soem functions that normally should be in ole32.dll), which is colored red'ish.
So far so good, i guess its somehow related to what the dependency walker shows there.
But where do i go from here? How do i fix it?
Any help would be greatly appreciated, that has been keeping me busy for several hours already.
Thanks!
I have the same problem. When I compared the different between "Command Line" (in Project Properties -> Linker) of Release and Debug mode, I found out that the "Optimization" options (in Project Properties -> Linker) of Release mode was turned on while ion Debug not.
Turning of Optimization for linker in Release mode solved the problem
Is it possible that the debug version is compiled with _ATL_MIN_CRT but the release version isn't? You can set this with the Minimize CRT Use in ATL project property as well.
I fixed it. It was actually being caused by the order of some mingw libraries i included to link against ffmpeg. Oh well, how weird.
In my case, the difference was in Module Definition File entry between DEBUG and RELEASE. The DEBUG version was pointing to the .DEF file where as the RELEASE had it empty.

Resources