I can compile the first gstreamer tutorial found here.
However, when try to run it, I get a warning like this:
(basic-tutorial-1:27661): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstffmpeg.so': /usr/lib/x86_64-linux-gnu/libavcodec.so.53: undefined symbol: lame_set_VBR_quality
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
How can I solve the lame_set_VBR_quality problem?
there are two unrelated problems reported in output:
gstffmpeg
on startup, gstreamer scans for available plugins and tries to load them.
among these plugins is the file /usr/lib/gstreamer-0.10/libgstffmpeg.so.
it seems that you have installed incompatible libraries (e.g. your gstreamer "ffmpeg" plugin depends on a different version of libavcodec.so), so the ffmpeg-plugin set cannot be loaded.
the problem is not really related to gstreamer itself, but rather to the way how you installed those libraries.
since linux-distributions usually are all about resolving inter-package dependencies (so that you can never install a package "foo-2.0" that depends on "bar-0.4" if you only have "bar-0.1" installed), i guess that you have added some non-official unsupported 3rd-party repositories (e.g. on debian, a common source of headaches is the deb-multimedia repository; other distros will have others).
if all libraries installed are from the official repository of your distro, chances are that you hit a bug in the packaging and you should report the bug to the maintainers of the package(s) providing the faulty libraries.
jack
the other "error" about jack not being able to start, is because the pipeline you are using uses the generic playbin2 element, which probes for available playback backends. while doing so, it also tries to connect to a running jack-server, fails to do so and (hopefully) falls back to another available audio framework.
One additional comment on the audio side. Check whether something simple as gst-launch audiotestsrc ! autoaudiosink works. Try again with pulsesink or alsasink instead of autoaudiosink. These 2 would be tried before considering jack.
Related
Currently, I’m experimenting with building Node.js projects (different bundlers and other kinds of stuff). And I got a simple idea about bundling Node.js to a single binary for Linux, macOS, or Windows.
There are two packages nexe and pkg both of them don’t really support native .node modules that are used by packages like bcrypt or realm. Were you performing a similar compilation? I would be extremely happy to see some real-world examples (I could not find them on GitHub).
But... for what? It's more like an idea for fun what we're able to archive with Node.js. Even if it will be working (I get it working on cjs packages without native modules) example project with hello wold may have a size above 30MB.
One cool observation is that #vercel/ncc is able to compile my project into a single directory, but it also doesn’t work without node_modules (probably, I had no environment to test it)
Update V1: Building realm is impossible in such kinds of projects, the simplest solution is to not use realm in node apps because it will crash the binary build (it's because realm is using tons of other packages such as electron or react-native which doesn't work at all when it comes to desktop platforms.
My code is available at the following repository: https://github.com/keinsell/typecraft
After days of struggling with researching how pkg works and searching for potential alternatives, I've found caxa which were working for me in a good way, and on the road, I also got pkg working fine with (actually only tested on bcrypt) native modules. My core insights on using pkg for building Node.js binaries are:
Use matrix-builds on CI to build package ex. win package from windows host, mac from macos host etc.
Be sure to include native modules to assets (there you can use require() function in JavaScript (example below) or use pkg.assets object in package.json - I don't really get it but it's contained in my issue on vercel/pkg - vercel/pkg#1473
+ require('bcrypt/lib/binding/napi-v3/bcrypt_lib.node')
export async function main() { /* ... */ }
Some modules are still build-crashing, and the good example is realm but I'll still search for a way of building it and including it into node.js binary application. All of my progress on researching Node.js builds will be available on https://github.com/keinsell/typecraft and this StackOverflow answer will be updated over time and my new discoveries.
Read this resource with examples and you will be able to compile it to a binary release. Of course, nexe is necessary but with pty.js you can successfully compile it with all the native libraries. Have a look at the source: https://www.jedi.be/blog/2013/05/14/compiling-packaging-a-nodejs-project-as-a-single-binary/
I've installed and executed (with nodejs) a package from npm: https://www.npmjs.com/package/openssl.js
Somehow I didn't realize that it hasn't a good reputation (almost no activity/stars on twitter, github). Now I'm afraid that it is a scam. The worst case would be that is stealing/encrypting my data or something like that.
I've checked the processes, I/O and network in the activity monitor but nothing interesting.
But I would like to have more confidence that everything is okay.
Since it is a Wasm file I cannot just check the source code.
I've tried to decompile with this tool: https://github.com/WebAssembly/wabt but it gives me for all binaries in that project this error: error: #0x00000004: bad magic value.
Maybe because in the README of the openssl.js package they claim it is build with wasienv toolchain?
Another idea would be install a honeypot and run the same commands in the honeypot. But which honeypot is suitable for this?
// edit
I was able to run wasm2c on this file: src/raw-wasm/openssl.wasm.
But how can I ensure there was no network interactivity?
Here are the first lines of the output: https://pastebin.com/YYHecFAC
Your application could not be compiled, because its dependencies could not be established.
The following Dart file:
C:\flutter\packages\flutter\lib\foundation.dart
...refers, in an import, to the following library:
C:\flutter.pub-cache\hosted\pub.dartlang.org\meta-1.1.5\lib\meta.dart
Unfortunately, that library does not appear to exist on your file system.
it says that you are trying to import a library that does not exist.try to run
flutter packages get that will get the packages you need and this might solve your problem
Thanks... I solve by running the
flutter packages get
Although I tried this before as a i was connected to slow internet, but the moment i was on a faster internet it worked... thanks
Sorry for the bad formatting, i'm new here.
Thanks to #nmittler on gRPC + SSL = UnsatisfiedLinkError I've got gRPC + SSL working on my Windows PC and on the target Linux platform.
But only when I specify a <classifier> for the io.netty/netty-tcnative-boringssl-static/1.1.33.Fork17 dependency. That can be:
hard-coded (e.g. to windows-x86_64)
injected using os-maven-plugin and ${os.detected.classifier}
But that means I can only run on:
Windows (or whichever platform I hard-code)
the platform I used to compile
But what I'd really like to be able to do is compile on Windows but run on Linux. So, in theory, I can just leave off the <classifier> to bring in the uber-jar (as specified in the docs).
But this doesn't work: when I step through io.netty.util.internal.NativeLibraryLoader.load() I find a call to System.mapLibraryName().
On Windows this correctly returns netty-tcnative.dll.
But on Linux (RHEL 7) it returns libnetty-tcnative.so ... which isn't in the uber-jar (jar tf netty-tcnative-boringssl-static-1.1.33.Fork17.jar returns, among others, META-INF/native/libnetty-tcnative-linux-x86_64.so).
Looking at the classified linux version of the jar I can see it contains META-INF/native/libnetty-tcnative.so ... which implies either the uber jar needs to be built differently (to rename libnetty-tcnative-linux-x86_64.so to libnetty-tcnative.so) or NativeLibraryLoader somewhere needs to take account of the different naming...
Am I on the right track? Can someone help fix this?
You're right, the uber jar on Maven Central does not contain the shared libraries. It's not yet clear whether the issue is building or deploying the jar. I've raised https://github.com/netty/netty-tcnative/issues/145 to track the fix.
Upgrading to io.grpc/grpc-all/0.14.0 (from 0.13.2) cured my problem because it brings in a newer version of io.netty/netty-handler (4.1.0.CR7 vs. 4.1.0.CR3).
Possibly this is related to Using a plugin generated with Firebreath in a Firefox Extension?; however, my question is possibly more specific, so here goes...
I'm working on Linux (Ubuntu 11.04), and I have built a Mozilla/Firefox (Firefox 7) plugin using FireBreath. The resulting plugin on this platform is an "npXXX.so" file, which I got symlinked in ~/.mozilla/plugins. Then, I have coded an extension that uses this plugin - and apart from the symlink, nothing else seems required - all seems to work just smashing :)
So, knowing that "firefox supports installing your plugin via XPI. This is not recommended by the FireBreath team", now I'd still like to package the extension AND the plugin into an XPI file. So, I'm reading a bit on Structure of an installable bundle - MDN, and I can see these two possibilities:
/components/* XPCOM components (*.js, *.dll), and interface files from *.xpt (>=1.7)
...
/plugins/* NPAPI Plugins (>=1.8)
...
binary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3
Now, it says: "The older XPCOM- and LiveConnect-based APIs for plugins should not be used.", so I guess the "/components" directory should not be used (even if it is given as an example in the above page). And I can not find this stated explicitly anywhere, but I'm guessing FireBreath builds NPAPI plugins - so presumably "/plugins" is the way to go. (There is also mention of "/platform", but it clearly says it's been deprecated for Firefox > 3.6).
Ok, so far so good... So I try to copy the plugin file to plugins/linux inside the extension directory:
cp -L ~/.mozilla/plugins/npXXX.so plugins/linux/
... and then insert the following in chrome.manifest:
binary-component plugins/linux/npXXX.so ABI=Linux_x86-gcc4
... then I zip the whole extension directory (the plugin included) as an .xpi, try to install it on a different computer. There, the .xpi succesfully installs, the .so file is indeed unpacked under the profile's extensions/XXX/plugins/linux/ directory - and every cross-platform (javascript) code of the extension works fine; except that the plugin cannot be found.
Now, of course, the user could themselves symlink the extension .so to ~/.mozilla/plugins/; however, I would like to spare the user of that :)
How would I go about this kind of packaging thing - is there a recommended way to do it?
Many thanks in advance for any answers,
Cheers!
Edit: found Shipping a plugin as a Toolkit bundle - MDN which claims only install.rdf , and a plugins/obj.so is needed; then I found Running Quake Live in Firefox 4, 5 and 6 on Linux [fixes inside], referring to a QuakeLivePlugin_433-modded_ff10.xpi, and that one does indeed follow such a simple structure.. If I install that, I get both a Quake extension and a Quake plugin (and that even with Error Console complaining "Could not read chrome manifest file '/path/to/extensions/quakeliveplugin#idsoftware.com/chrome.manifest'.") .... but if I try the same with my FireBreath plugin (e.g. just an install.rdf and plugin in /plugins), only extension gets shown - no plugin (and no reasonable error messages).. Could this be a problem with FireBreath?
Well, I'll post this as an answer - I have just confirmed that FireBreath plugin does in fact work being packaged in the simple "toolkit bundle" way as an .xpi extension.
Basically, I just cleared up my development PC's Firefox profile, and tried to install the .xpi carrying the plugin there - and on the dev PC, the plugin shows in about:plugins and runs just fine (even if it's just unpacked in profile/extensions/EXT/plugins/obj.so, and not in ~/.mozilla/plugins)... In fact, I packaged both the extension and the plugin in separate .xpi's, which were then merged in a single one as recommended in Multiple Item Package - MDN - and that works fine too (upon loading the merged xpi, one gets prompted about installing two extensions - one for the plugin carrying one, and the other for the "plain" extension)...
So the problem was on the other test computer only - and the problem seems to be that I'm using Gnome libraries in the plugin, and while my dev PC is Ubuntu 11.04 - I think this test PC was Ubuntu 10.04 ... So, quite likely, the problem is incompatible Gnome libraries in the plugin build; unfortunately, I don't get many errors back from firefox, even if I do:
NSPR_LOG_MODULES=IPCPlugins:5 NSPR_LOG_FILE=/tmp/plugins.log /path/to/firefox -P myprofile
(... as recommended in Logging Multi-Process Plugins - MDN - however, the /tmp/plugins.log remains empty). The only thing Firefox on the problem machine spits is something like this to stdout:
WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported! This is an application bug!
WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported! This is an application bug!
(firefox:6548): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:1149: unable to lookup signal "text-insert" for non instantiatable type `AtkText'
... and I cannot tell if this has something to do with the plugin or not... But I guess at least the packaging part got confirmed as working now :) Cheers!
EDIT: After a while, the Firefox on the test PC did spit out the following (although I would have expected this message to pop up instantly):
LoadPlugin: failed to initialize shared library /path/to/profile/extensions/extXXX/plugins/npXXX.so [/usr/lib/libstdc++.so.6: version ``GLIBCXX_3.4.14' not found (required by /path/to/profile/extensions/extXXX/plugins/npXXX.so)]
... which finally confirms it was a build problem I have had.