When trying to compile my ghcjs/jsaddle based Haskell website, I get
Main.hs:20:1: error:
Failed to load interface for ‘GHCJS.DOM.Element’
It is a member of the hidden package ‘jsaddle-dom-0.9.2.0’.
Perhaps you need to add ‘jsaddle-dom’ to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
even though jsaddle-dom is already in the build-depends of my cabal file.
So I can't do what the error message suggests.
What's going on?
You should put build-depends: ghcjs-dom instead of build-depends: jsaddle-dom in your cabal file.
This is because ghcjs-dom is the multiplexer between the real ghcjs-dom-jsffi and jsaddle-dom.
Check out the ghcjs-dom cabal file to see that.
Why is ghc's error message so misleading? Thanks to jonored from the #reflex-frp freenode IRC channel for this explanation:
ghcjs-dom is just a reference to the module in jsaddle on that platform.
so it's not where it actually canonically is, and ghc tells you about where it is. But you want ghcjs-dom, so that it tells you the ghcjs-based implementation on ghcjs.
Related
I'm porting my Windows Mono application to Linux, one step at a time, first to WSL Linux under Windows 10, then hopefully to Real Ubuntu. Everything described here behaves identically under both WSL and Ubuntu 20.04.
My application loads the /usr/lib/libmono-2.0.so shared library, but in doing so the loader throws an exception: undefined symbol: _ZTIPi. Some research showed that this symbol was defined in libstdc++.so, so I "pre-loaded" that as well. That had no effect.
Meanwhile, I found this code fragment perusing the mono code base. It would be in mono\mini\mini-llvm.c: (https://github.com/mono/mono/blob/main/mono/mini/mini-llvm.c)
/* Add a reference to the c++ exception we throw/catch */
{
LLVMTypeRef exc = LLVMPointerType (LLVMInt8Type (), 0);
module->sentinel_exception = LLVMAddGlobal (module->lmodule, exc, "_ZTIPi");
LLVMSetLinkage (module->sentinel_exception, LLVMExternalLinkage);
mono_llvm_set_is_constant (module->sentinel_exception);
}
What exactly is happening here? What do I need to know and understand to successfully load this library?
Solution so far was to build and install Mono outside of the default release.
See https://www.mono-project.com/docs/compiling-mono/linux/
then One Stop Shop Build Script (Debian)
If you follow the instructions, your alternate Mono installation would be in /usr/local
This would suggest that the Mono release was somehow incorrectly compiled.
So, having found this after having the same issue, thank you for the information in the question and answer, it helped me figure out how to solve it. However, your solution doesn't answer your "What exactly is happening here?", which I shall try to explain.
Let's start with the _ZTIPi symbol, which when run through c++filt comes out as: typeinfo for int*
Which is indeed a part of the C++ standard library. It is listed as undefined in the default install of libmono, but not listed at all in the one I compiled from source.
You can check this with something like:
$ readelf --all /usr/lib/libmono-2.0.so | grep _ZTIPi
However, libstdc++.so isn't listed as needed library in either case.
You can check this with something like:
$ readelf --all /usr/lib/libmono-2.0.so | grep NEEDED
This all means that when you try to load in libmono the dynamic linker will try to resolve the _ZTIPi symbol by looking in the libraries listed by libmono (where it can't find it), and in the global symbol table for the process, which may or may not have it.
If you link against libmono at compile-time the solution would be to also link against libstdc++ at that time. This way, your executable will list libstdc++ as needed library, causing the dynamic linker to load its symbols into the global symbol table. When loading libmono the dynamic linker can then find the symbol fine.
If you load libmono dynamically at runtime, you'll have to load in libstdc++ first, using something like this:
void * cxxlib = dlopen("libstdc++.so.6", RTLD_LAZY | RTLD_GLOBAL);
Key thing here is the RTLD_GLOBAL flag, which will add all symbols to the global table, so they can be found when you're trying to load libmono.
And alternative is of course to build mono yourself, which should end you up with a libmono that isn't subtly broken. In that case, make sure to throw in a call to mono_set_dirs, like this:
mono_set_dirs("/opt/mono/lib", "/opt/mono/etc");
I know it can be done, but I'm having trouble getting it working. I'm still finding my feet with Haskell.
I tried using postgresql-typed, but it wouldn't compile. They don't enable the QuasiQuotes extension, so I don't understand how their code would ever compile. It also fails with an error on the useTPGDatabase statement. I cloned the library's source code from Github, but their tests failed to compile using stack with exactly the same errors.
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket.". I considered switching to nix but that seems like even more effort.
Does somebody have a reliable recipe for getting an environment working that type-checks SQL at compile time in Haskell?
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket."
All you need to do is add the latest version of hasql-th to the extra-deps section of your stack.yaml file and all other deps that Stack will suggest to you when you build.
In the end your stack.yaml file should look something like this:
resolver: lts-17.9
extra-deps:
- hasql-th-0.4.0.8
- headed-megaparsec-0.1.0.4
- postgresql-syntax-0.3.0.3
Anticipating a question in the spirit of "Why is it not listed on Stackage?" It's just that nobody has gotten to list these packages yet.
I am about to test GHDL and Yosys as a replacement of EDA proprietary design flows, for my students. My point is about VHDL synthesis.
I have a fresh install of several tools : trellis (ECP5), yosys, nexpnr, fujprog (ulx3s).
GHDL is also installed for a longer time but it is supposed to include synthesis also (--synth option works).
ghdl -v
GHDL 1.0-dev (v0.37.0-208-g2c66a8bd) [Dunoon edition]
Compiled with GNAT Version: Community 2019 (20190517-83)
llvm code generator
It seems that I also need ghdl-yosys-plugin. However, the install does not work for me.
I get a bunch of error messages :
make GHDL=/opt/ghdl/bin/ghdl
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/opt/ghdl/include -O
src/ghdl.cc:361:2: error: unknown type name 'Attribute'
Attribute attr = get_first_attribute (inst);
^
src/ghdl.cc:361:19: error: use of undeclared identifier 'get_first_attribute'
Attribute attr = get_first_attribute (inst);
^
src/ghdl.cc:379:7: error: use of undeclared identifier 'Id_Posedge'; did you mean 'Id_Edge'?
case Id_Posedge:
^~~~~~~~~~
Id_Edge
etc
I am missing something. Can someone help ?
Thanks in advance
JCLL
As I suspected (despite versioning that seemed correct), a fresh new install of GHDL fixed the issue.
i did some investigating: ghdl has undergone some restructuring, for proper FHS compliance. for example this commit https://github.com/ghdl/ghdl/commit/66cd5e0aa897b947533d269535fde4c0852472c2 and further commits show some renaming which ensures compliance with FHS conventions. files that used to be installed as /usr/local/include/ghdhsynth.h are now in /usr/local/include/ghdl
however because there are two completely separate pieces of software involved here (ghdl and yosys-ghdl-plugin) you have to (a) keep them in sync and (b) ensure that prior-installed ghdl headers are manually cleared out HOWEVER
manually deleting the installed files in /usr/local/include and reinstalling may not help if you cross over the threshold of commits from stable to developer releases on one but not the other, because older versions of yosys-ghdl-plugin were also not FHS convention-compliant. or, if you don't get them exactly right (i had to check the git log commit timestamps for both ghdl and ghdl-yosys-plugin in order to get a match), you get the general idea
if you really want to use a mis-matched version of ghdl and ghdl-yosys-plugin (YMMV here) then there are a few solutions:
manually copy the files in /usr/local/include/ghdl into /usr/local/include. this is a really dreadful hack that will need repeating each time you re-install ghdl.
modify the yosys-ghdl-plugin Makefile to include "-I/usr/local/include/ghdl" in CFLAGS or ALL_CFLAGS
in ghdl/synth.h and anywhere you see ghdl/synth.h used replace it with just "synth.h", likewise with synth_gates.h.
bear in mind that all of these are absolutely awful, totally not guaranteed to work, and you are way better off making sure that the versions being used are properly in sync.
it also does not help that some things from yosys latest master are also being removed, on which yosys-ghdl-plugin relies, to compile! as of writing i have found that tag yosys-1.13, ghdl-plugin commit c9b05e481423c, and ghdl commit 263c843ed49 will compile and work. however if i update to latest ghdl master (0e46300) microwatt fails to build, so i am sticking with 263c843 for now.
YMMV, hopefully however that gives you some insights rather than considering these complex and fantastically useful pieces of interlinked software to be opaque black boxes.
When serving lit-element components with nollup then I keep getting the following error in the browser console that I am not able to track down:
toast-messages.js:56 Uncaught TypeError: modules[number] is not a function
at create_bindings (toast-messages.js:56)
at toast-messages.js:57
at Object.48 (toast-messages.js:365)
at create_bindings (toast-messages.js:56)
at _require (toast-messages.js:141)
at toast-messages.js:249
at toast-messages.js:251
Can anyone point me in the right direction? (I can share my rollup.config.js if required)
This error means that a module has been requested, but there's no module with the specified id (number) included in the bundle. This can happen for a variety of reasons:
There's a call using require passing an invalid id.
Passing a string or something other than a number into require.
Using a library that was compiled to CommonJS but was not transformed to ESM.
It's likely that you're missing the CommonJS plugin, or if you are, then the CommonJS isn't able to catch the require call and convert it. The latter can happen because of obfuscation in the library code. CommonJS plugins work by using static analysis. It would be very difficult for the plugin to transform the following:
var r = require;
r('my-library-code');
Without executing the code, it would be difficult for static analysis to track this. A best effort attempt can be made, but there will be always a situation where it could fail.
So here's the following steps you should take:
* Confirm that the CommonJS plugin is being used.
* If it is, check the file in node_modules for unusual patterns.
* If there is, file an issue with the CommonJS plugin maintainer and see if it's possible to solve, and if not, you might need to contact the maintainer for the toast-message library.
I do realise I'm posting this very late, but better to answer later than never! To avoid this vague error in the future, in 0.10.2 of Nollup I've added a user friendly error that list some things to check for.
Hope this helps!
I get two warnings at the cpp compile phase with all the stan programs that I submit.
C:/Larry/R/win-library/3.4/BH/include/boost/config/compiler/gcc.hpp:186:0: warning: "BOOST_NO_CXX11_RVALUE_REFERENCES" redefined # define BOOST_NO_CXX11_RVALUE_REFERENCES
and
cc1plus.`exe: warning: unrecognized command line option "-Wno-ignored-attributes"
Since I don't get these warnings in submitting other Rcpp programs, I suspect that they are generated in the course of gc++ compiling of the Stan program. They seem to be harmless, but they are disconcerting. I see many other messages on Stack Overfkiw that include these warnings, but I have not found any explanations of them, nor ways to correct what is producing these warnings.
I am running R 3.4.3 and RStudio 1.1.383 in Windows 10 with Rtools 3.4.0.1964. I'd be grateful to anyone that will explain these warnings to me and what I have to do to correct them.
Don't worry about either of those.
The first is telling you that it redefines that Boost thing, but it is redefining it to what it was already set to.
The second is avoidable if you take -Wno-ignored-attributes out of the CXXFLAGS line of your ~/.R/Makevars file. It applies to a different compiler or version or something and is being ignored.