I am trying to install mod_java on ubuntu.
I have installed the latest java(1.6).
I have configured freeswitch with mod_java module enabled in module.conf.xml
then when i run the make file, it says:
freeswitch_java.h:5:17: error: jni.h: No such file or directory
I have searched through the java installtion folders, but did not find any include folder or jni.h.
Can anyone help, what is being the problem here.
Thanks for reading this question.
I had the same problem. The solution was to run configure with the option --with-java:
./configure --with-java=/usr/lib/jvm/java-1.6.0-openjdk/include/
I don't know if it makes any difference but I added mod_java after building freeswitch without it. It was disabled in my initial build in module.conf.xml but afterwards I ran the above command plus:
make mod_java-install
It worked for me on ubuntu with openjdk. Are you using the Sun JDK? Maybe in the version you have dont have the include folder which has the source files. Try installing the other JDK. Or try and see of ther are some other related packages in apt that will get you the include folder.
Type this linux command to locate your jni.h file on your filesystem.
locate jni.h
you should be able to get it somewhere
in /usr/lib/java directory or some other directory
depending upon your java home.
copy paste the jni.h in src/include folder of your freeswitch src.
It will throw you some more errors for different .h files
just copy all of them to your src/include folder.
in latest freeswitch, installing through Makefile, its not possible to configure as the Makefile downloads and installs. Its possible by modifying the Makefile.in file to add the include path
mod_java_la_CPPFLAGS
-I/usr/lib/jvm/default-java/include \
Related
When I try to install openFL with Haxe I get this error:
C:\Users\Dude>haxelib install openfl
You already have openfl version 3.3.0 installed
[file_contents,C:\Program Files (x86)\Stencyl\plaf\haxe\lib/openfl/.current]
I have uninstalled Stencyl from program files (Win8.1_64bit) and ran CCleaner to make sure I was wiped out. Also I checked system and user environmental variables but didn't found Stencyl anywhere.
Then I have reinstalled Haxe over again, but for some reason I keep getting the same error.
After the fresh installation, I have checked the installation location of Haxe by using the >haxelib config command but still I get this weird output
C:\Users\Dude>haxelib config
C:\Program Files (x86)\Stencyl\plaf\haxe\lib/
Currently haxe is installed at C:\HaxeToolkit on my machine
Well I just entered the Stencyl keyword in the windows search bar and saw this file: .hxcpp_config.xml. This file and another one called .haxelib was located in my user Home folder.
The problem was fixed after deleting both of this files.
Also I found were stencyl was hiding (ಠ_ಠ ). The file .hxcpp_config.xml directs to the AppData folder in the user directory (C:\Users\Dude\AppData\Roaming\Stencyl)
I installed tcl to learn it, however, I installed all the files in the wrong location. I am trying to uninstall it, But the uninstall file does not work. I am trying to carry out the instructions form their website:
To uninstall ActiveTcl, run the "uninstall.tcl" script that is located in the directory where you extracted the ActiveTcl archive. Note that you must use the "wish" in the distribution you wish to uninstall. For example:
% /path/Tcl/bin/wish /path/Tcl/lib/ppm/log/ActiveTcl/uninstall_ActiveTcl.tcl
stored, by default, in the directory /lib/ppm/log/ActiveTcl. You must use the wish interpreter from the distribution you wish to uninstall. Ensure that you do not run the uninstall script from a directory that will be removed during the uninstallation.
For example:
% /path/Tcl/bin/wish /path/Tcl/lib/ppm/log/ActiveTcl/uninstall_ActiveTcl.tcl
Note: if you are uninstalling both ActiveTcl and Tcl Dev Kit, uninstall Tcl Dev Kit before uninstalling ActiveTcl.
There is no uninstall_ActiveTcl.tcl. I do see an "uninstall" file but it does not have an extension, and I do not know how to run it.
Any help is appreciated
Thank you
Try editing the file to a uninstall.tcl file and see if that works. Take a back-up first though. Because we might need that file later
I re-installed it in a new location, compared the files that were installed between the old and the new location and deleted the file sin the old location. Unfortunately I could not delete many of the hidden files, as I did not know if they were there originally or if they belonged to Tcl. I am really surprised and disappointed there is no easy way to uninstall tcl properly.
I strongly suspect that you should uninstall ActiveTcl as follows:
Open a command prompt
Change directory to where you found the install file - e.g.
$ cd path_to_Tcl_installation/bin
Run the file
$ ./uninstall
On linux systems, you don't need any particular file extension in order to be able to run a file.
I don't know CentOS but a little googling led me to a forum thread that describes how to open a command prompt.
Good luck
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.
I've just been setting up a Ubuntu workstation and wanted to add some settings to eclipse.ini. When I searched for the file I found:
/etc/eclipse.ini
/usr/lib/eclipse.ini
My questions are:
Does Eclipse actually use both files?
If so, in what order does it read them?
How does it merge them?
Both of the files I found are system wide, is there a location in my home directory I could put one that would effect only my instances?
Here's how to determine which eclipse.ini file you should use (joomla.org):
If you downloaded Eclipse IDE manually from internet the "eclipse.ini" file is just inside the unpacked folder
If you installed Eclipse via terminal or software center the location of the file is "/etc/eclipse.ini"
In some Linux versions the file can be found at "/usr/share/eclipse/eclipse.ini". Do not use this file if you found a config file at "/etc/eclipse.ini".
To be sure where your Eclipse folder is, check $ECLIPSE_HOME, and if not specified (these directions at least work for Juno):
Open Eclipse as you normally do.
Click Help -> About Eclipse SDK
Click Installation Details
Go to the Configuration tab
Find "eclipse.home.location=file:PATH". PATH is where eclipse is installed.
sources:
http://docs.joomla.org/Configuring_Eclipse_IDE_for_PHP_development/Linux:
There is only one file.
lrwxrwxrwx 1 root root 16 Aug 8 2012 /usr/lib/eclipse/eclipse.ini -> /etc/eclipse.ini
You probably have already found this out, chances are when you installed Eclipse the installation created (or you did manually) a file /usr/bin/eclipse which if you check it probably looks like the following:
#!/bin/sh
export ECLIPSE_HOME="/opt/eclipse"
$ECLIPSE_HOME/eclipse $*
especially if you followed instructions similar to the ones like these on If-not-true-then-false
On the other hand if you have installed from a package, I suspect you will find that eclipse ends up in /usr/bin, most likely a symbolic link to /usr/lib/eclipse/eclipse (or at least I found it on my Fedora system after using yum to install eclipse).
I have Ubuntu 18 and eclipse installation is squashed in a file
/var/lib/snapd/snaps/eclipse_40.snap
which is mount on /snap/eclipse/40 as read only. Just run
mount | grep eclipse*.snap
This eclipse.ini file is really read only, that means, you cannot modify it, even with sudo. However, I also have a eclipse.ini.ignored file in HOME/.eclipse/some number/configuration. This is being by default ignored, but you can change the "launcher.ini" in the eclipse launcher command.
According to https://wiki.eclipse.org/Eclipse.ini
Eclipse startup is controlled by the options in
$ECLIPSE_HOME/eclipse.ini. If $ECLIPSE_HOME is not defined, the
default eclipse.ini in your Eclipse installation directory (or in the
case of Mac, the Eclipse.app/Contents/MacOS directory) is used.
The certain way to make sure is to run strace on eclipse. In the output you'll see where is eclipse actually trying to pull the file from.
I´m doin a unattended cygwin installation and I was wondering if there will occure any problems without a setup.ini.
Following: my "install-folder" includes a setup.exe and a subfolder release (within all the packages packed).
I´m starting the setup silent (with Nsis) and install the packages. In NSIS I define the Root, the location of the packages etc.
I think it works so far (I´m not sure because i´ve got a curious error in cmake). There are many instructions how to modify the whole setup for an offline installation. But I don´t get the point why I have to modify it at all.
I hope anyone has got experience with this issue!
#Daniel Le cygwin installs the packages without the .ini (all of them). And there has nothing to be downloaded because the packages are on the local machine.
I believe the setup.ini is essential to the setup process, as it indicates which packages to be downloaded and installed.
The Ini file is so far only a description for file locations and paths to be set as default. It is not necessary to have the ini file if you wanna install some packages!
That´s my conclusion.