I followed the instructions in GStreamer Plugin Writer's Guide (1.7.1.1):
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
in order to build a new gstreamer plugin. Basically I ran make_element and then edited Makefile.am as described. Amazingly make and make install worked and I ended up with:
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.la
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.so
As I understand it, gst-inspect should find this plugin automatically. The guide says that /usr/local/lib/gstreamer-1.0 needs to be added to GST_PLUGIN_PATH in order for plugins in this directory to be found. Another document states that this directory is searched automatically. I tried with and without the environment variable, but no luck.
Now I should say that I have just started to use gstreamer and I am suffering from total information overload. I have read so many documents, yet I don't even know whether I am building a gstreamer1.0 or a gstreamer0.10 plugin (I think the guide is for gstreamer1.0, since the guide's version is 1.7.1.1 but can't be sure).
Can anybody give me a clue here ?
There are many possible reasons that can cause this issue.
First, check if your plugin is blacklisted by command gst-inspect-1.0 -b.
If your plugin show up here, that means it is really blacklisted.
In that case, delete directory ~/.cache/ and then run gst-inpect-1.0 again.
This will force GStreamer to re-scan plugins list. If the reason of blacklist is not solved yet, gst-inpect will probably print out the reason here for you.
Another possible reason (but unlikely happens) is setting GST_REGISTRY_UPDATE as no, which will force GStreamer NOT to rescan the plugin directory, thus not found new plugin
P/s: The guide is for GStreamer 1.0
If you've tried removing your plugin from the blacklist and it still doesn't show up, try this:
export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0
/usr/local/lib/gstreamer-1.0 is the default directory used by make in case of plugins. If you have defined a different directory, use it.
Then run gst-inspect-1.0 and you'll find the newly compiled and installed plugin.
You'll be required to perform the export every time in the shell whether you either create a static pipeline with gst-launch-1.0 or run code of your own. I couldn't find any alternative to make it permanent other than making entry of this in .bashrc file. If you have one, please suggest via comments.
If you run ./configure --help in the gst-plugin directory you will see the following:
By default, make install' will install all the files in
/usr/local/bin', /usr/local/lib' etc. You can specify
an installation prefix other than/usr/local' using --prefix',
for instance--prefix=$HOME'.
If you do after the original installation:sudo updatedb && locate libgst[NAME_OF_YOUR_PLUGIN].so you should see where the library holding your plugin is located (in my case it is under /usr/local/lib/gstreamer-1.0/ as described by the configure help above).
Now on my machine, the GStreamer "official" plugins are installed under: /usr/lib/i386-linux-gnu/gstreamer-1.0/ . This is where the new created plugin library should be stored.
To store the plugin at the right place, run configure with the following parameter:
./configure --libdir=/usr/lib/i386-linux-gnu followed by make && sudo make install
It is important to override with --libdir and NOT --prefix! The usage of --prefix will stick a /lib that we don't want to have under /usr/lib/i386-linux-gnu.The plugin will not be found by gst-inspect-1.0 if /lib is added to the path.
Extra note :
Even if the plugin is at the proper location, you may still see GStreamer blacklisting it when you run gst-inspect-1.0. One of the cause of the blacklisting could be the shared library/ies required by your plugin not installed or not found on your platform. The ldd command can help figuring out the dependencies your plugin may have. Just run ldd [YOUR_GSTREAMER_LIBRARY].so
Related
Although I've been using github for a while, but every now and then this problem pops up. From a github project, how do I know which filed/folders are actually what I need?(Generally, I don't need those files that are only used by developers)
Take this project (https://github.com/mupchrch/split-diff) for example, I am trying to install this plugin into my Atom editor so I can compare two files, but I find very little is said about how and which files are to be installed/copied, and to where. This "lack" of information happens to many many github projects I stumbled with. Some indicates npm install xxx which I am OK with, some says nothing at all, like the above example. So I conclude I must have missed some very important information regarding how to use github package, something that goes without saying.
Can anyone help me or give me any hint?
I noticed that here is a package.json file, which must indicate this package can be installed by npm. But I need more specific instructions:
Do I need to download all the files and folders? To where? And where do I launch npm install? Or as far as I know, Atom editor has its own install command (apm is it?), where do I run this apm?
I'm new to collectd and Riemann. Im essentially trying to direct collectd logs to a riemann server instance. I understand that I need write_riemann plugin installed. I tried compiling the source files for write_riemann available online, but it includes a file called "riemann.pb-c.h", which is no where to be found. Please help!
Download the binary. After running the build script, while running the configure script include "--enable-write_riemann", this should install it. I had a lot of dependencies missing on CentOS, which threw a lot of errors. Once they were installed, write_riemann plugin was compiled and installed. Another issue you might face while installing the dependency is not able to find the right packages for protobuf-c.I was using yum package installer. Go to sudo vi /etc/yum.repos.d/epel.repo and change enabled from 0 to 1. After this, the protobuf-c processor was recognised while running the configure script. This solved my issue. Hope it does yours too!
I have gone through the following steps:
$ mkdir mongoEg
$ cd mongoEg
$ cabal init
...
Configured to run as an executable. I add mongodb to the build-depends list. I make a dummy Main.hs file and put a basic hello world in there. I then do
$ cabal sandbox init
$ cabal install --only-dependencies
Which responds with:
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: monogEg-0.1.0.0 (user goal)
next goal: mongodb (dependency of monogEg-0.1.0.0)
Dependency tree exhaustively searched.
Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.
I read up on other problems people are having, and remove ~/.ghc, remove my mongoEg directory, and repeat to get the same results. I try to run through the analogous steps at http://howistart.org/posts/haskell/1 and find that everything works just fine.
I then guess that something is wrong with the mongodb package itself. I seem to be able to cabal install mongodb in a global environment and use it outside of a sandbox without any issue. So, why wont cabal sandboxes play with the mongodb package?
See this gist for details: https://gist.github.com/anonymous/e5a548cf7d9ec59bea31
After looking here
Cabal configure in a sandbox complains "At least the following dependencies are missing" on installed packages
I saw that the answer states that package names are case sensitive. So I tried changing mongodb to the way MongoDB spells it, namely MongoDB. This did not work, so I tried changing it to mongoDB, and finally there was joy.
So even though I can do cabal install mongodb I can't use that same spelling to install it from within a .cabal file, which is, obviously, completely stupid. I'm sure I'll find the right place to channel my rage about this kind of flagrant violation of the principle of least surprise, but for now I can say that to newcomers it is most needlessly confusing.
I have installed sublime and go.
Tried the autocompletion feature offered by https://github.com/nsf/gocode.
It works perfectly for standard packages.
But not working for external packages like the ones fetched from github.
Any help on this appreciated. Thanks.
It will only work if you build and install those external packages.
if you just go get their sources, the completion won't work, even said sources are in the GOPATH/src/....
Those packages need to be at least compiled (GOPATH/pkg).
As mentioned in "How does Go update third-party packages?", a go get -u all can help.
For go autocomplete to work (Atom Editor, Sublime, even vim with autocomplete)
Your package must be placed in the go path. (this can be automatically done if the project is on github and you use the get tool)
go get -u github.com/username/packageName
you must build your package
go build $GOPATH/pathToYourProject...
you must install your package
go install $GOPATH/pathToYourProject...
As asked and answered here, python has a useful way of deployment without installers. Can Java do the same thing?
Is there any way to run Java's jar file without installing jre?
Is there a tool something like java2exe (win32), java2bin (linux) or java2app (mac)?
You can use Launch4j for this. Well documented and easy to use. While the resulting program still needs a JRE to run, you don't have to install the JRE on the target system. You can just copy it with your application and tell Launch4j were to find it or just wrap it up with everything else.
For creating native executables, you can use Excelsion Jet, which compiles Java to native code. We used it for a project at work, and we had to perform zero modification to the original source code (which targetted Sun's JDK).
you can embbed the JRE inside your application and create a setup or installation for your application.
You can have a look at
http://www.bearcave.com/software/java/comp_java.html
You might get it what you want.
You might want to check out how Eclipse does it - it has a native .exe that can use a local (to the installation) JRE.
You might be able to get some luck with GCJ - haven't tried it myself.
You can do it with NetBeans and a couple of tools. The result is a standalone installer that packages everything you need, so your software can run without installing JRE. It is also completely portable, because it install your software on AppData, that is, it does not need privileges to be installed. Maybe you can even configure the installation path, or you can install it on your own PC, locate the folder and copy it to distribute your software in that way.
Check the Answer I made on different post
You can use jlink to create your own customized jre which would contain only those dependencies which are needed for execution. This deployment method is really efficient. please follow **this**link for one such example.