I am currently having an issue with trying to use the -mlarge flag with the MSPGCC compiler on an MSP430, its throwing the following error for all the generated objects in my code:
/user/local/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/bin/ld: error: /home/ewheatland/repos/Embedded/driverlib/MSP430FR2xx_4xx/lib/adc.o uses the small code model whereas /usr/local/ti/msp430-gcc/bin/../lib/gcc/msp430-elf/9.3.1/../../../../msp430-elf/lib/large/crt0.o uses the large code model
I believe this is due to -msmall being the default configuration however Im not sure how to change it to -mlarge when compiling.
Ive currently tried passing the flag -mlarge to the linker as well using: -Wl,-mlarge however that ended up not being a valid flag for the linker.
Related
I am trying to add an external FORTRAN Code to OpenModelica 1.13.0. My function and model definitions are correct and the FORTRAN code normally works. But whenever I add a write(*,*) or read(*,*) method to the code I get the following error as OpenModelica Simulation output:
undefined reference to _gfortran_transfer_real_write##GFORTRAN_1.4
I wonder how can I solve this issue.
Thank you.
This (probably) happens because you are not linking gfortran with the simulation. If the library is shared (so, DLL, dylib), the dependency is usually handled automatically, so you are probably trying to link a static library (.a) or object file (.o, .obj).
In your external function, add an annotation Library="gfortran" or since you probably already have your library in there, Library={"mylib", "gfortran"}.
Also note that OpenModelica 1.13 is getting old and should be upgraded.
For OMShell one can call the setCFlags("-lgfortran") or inside OMEdit add -lgfortran at Simulation Setup > General > C/C++ Compiler Flags. It will solve the issue.
I'm using VSCode with the python extension. The 'problems' tab as well as the indicators on the 'explorer' tab and the red underline in the code view itself all show there to be an error, even though the error isn't real.
After importing matplotlib.pyplot as plt, the code uses plt.cm.RdBu. VSCode is presenting the error that matplotlib.cm has no member RdBu.
There are two issues here:
Unless I'm just mistaken, plt.cm.RdBu ought to be equivalent to matplotlib.pyplot.cm.RdBu, not matplotlib.cm.RdBu. It seems to be interpreting that incorrectly.
But regardless of that, both cm and pyplot.cm actually do have an attribute called RdBu, both of which I was able to pull up information for using help(). The code runs perfectly and python throws no errors.
Why is VSCode telling me this is an error when it isn't? Is this just a bug or could it be a misconfiguration?
Unfortunately, there doesn't seem to be a way to fix this issue. The reason that VS Code, or more specifically, the linter used by the Python extension isn't picking up matplotlib.pyplot.cm.RdBu, or any other colormaps defined in cm is because they're defined dynamically. If you try looking inside cm.py, you'll only find this:
cmap_d = _gen_cmap_d()
locals().update(cmap_d)
Essentially, instead of being statically defined like RdBu = ..., these colormaps are defined dynamically by being injected into the module's global namespace at runtime. Even though this works fine when you run it, unfortunately it means that there's no way for the linter to know that names such as RdBu exist in the namespace until runtime. And as most linters such as pylint and flake8 are static code analysis tools that never actually execute the code, it's impossible for them to detect the existence of these colormaps.
I ran into the following error which is quite surprising. I added a field to the AppSettings in a Yesod app (using the Yesod scaffholding) and to my surprise, everything compiled even though I didn't do anything else (I was expecting to have to add somewhere a default value to the construction of AppSettings, but not). I got a runtime error instead telling me that a field was missing.
It appears that the only construction to AppSetting uses the RecordWildCards extension and looks like AppSettings{..}. Not defining the new field didn't generate an error but a warning (I didn't see it, because I was running test in continuous mode using stack test --file-watch). How is that possible ?
I try to reproduce the problem in a simple file and I get an error not a warning. So why do I get a warning for Yesod ? Is it a compilation flag or something ?
Edit
This is not specific to Yesod. I've made the test again with a simple file and it generates a warning not an error.
According to changelog in GHC, "that not a bug, it's a feature": https://ghc.haskell.org/trac/ghc/ticket/5334
You can change this behavior by changing type of your fields to strict (prepend a ! to type name - like !Int) - however, then you lose laziness (more about effects of strict types: Advantages of strict fields in data types)
Of course, you can also make it an error by slamming in -Werror compilation option, but then you need to be very strict about your code (no unused imports, no unused variables, even when unpacking a record etc.), or get rid of -Wall and turn on only warnings you perceive as important.
I have a project that is running fine on Android and WinPhone 8. When I attempt to run on iOS, I've getting the following error
Microsoft.Practices.ServiceLocation.ActivationException: Cannot
register: No public constructor found in x
where x is whatever SimpleIoc.Default.Register<T, TU>(); the flow hits first. I've moved the code around (as suggested elsewhere) to ensure all of the platform specific SimpleIoc calls are made in ViewModelLocator.
I've added public default ctors in the classes that are complaining about the error (I have though set the PreferredConstructor to the original, not the newly added public ctor).
I have a feeling that this error is a false positive (something else is failing, but pointing at that code).
Using Xam.iOS via a build server (the code is coming from VS2015). Xcode is running the 8.3 emulators (it may need updating to allow for 8.4 testing)
It could be that the Linker is optimising away the constructor, if it thinks it's not used. Try setting the Linker Options to "Don't Link" and see if it does it again, or even new-up an instance of the class elsewhere so that the Linker knows that the constructor is used. You don't necessarily want to leave it that way, but if it eliminates the error, you'll at least know the reason.
The [Preserve] attribute did the trick for me.
Decorate constructor with it and keep your linker settings.
This attribute is part of the Microsoft.WindowsAzure.MobileServices namespace.
I am trying to run the PumpingSystem Example in the openmodelica Fluid library using the nightly build 1.9.1+dev (r21018). Unfortunately the simulation crashes saying it failed to solve NLS at initialization.
I tried to modify the model either by creating a new one extending it (which only permits the modification of the parameters but not the structure, I understand that this is probably what extension means) or by copying the text view of the model to a new file, but then OMEdit crashes.
Will you please advise how I can create a copy that I can modify?
Thank you.
PS: I am running this on Linux, the Windows version seems to translate all libraries,creates an infinite amount of translation errors "expected package to have within ; but got ..." and then terminates with a translation error "C:/OpenModelica1.9.1Nightly/lib/omlibrary/Modelica 3.2.1/Blocks/Continuous/Internal/Filter/Utilities/normalizationFactor.mo:14:3-42:27] Error: An element with name normalizationResidue is already declared in this scope."
You can not modify the system libraries. You can only extend them.
Creating a copy of the model is currently not supported. You can follow this ticket https://trac.openmodelica.org/OpenModelica/ticket/2190
If you just copy paste the text, as you already did, you need to manually update the relative paths used in the model.