I'd like to install several unix utilities (incl. xmlstarlet, wget) on a solaris 10 machine which I don't have root access to (obviously, I have a user account). I'm not that experienced with solaris and am wondering if I can simply get hold of an uber binary for each utility I need and just place this in my home directory? Is this feasible?
Many thanks
wget is installed by default on Solaris 10 in /usr/sfw/bin/wget.
xmlstarlet requires four libraries that aren't included in Solaris 10 so it's going to be trickier but of course, you can build them and then xmlstarlet from their respective source code.
Have a look there for information about what is needed: http://www.opencsw.org/packages/xmlstarlet
If you really don't want to compile the binaries, there is certainly a way to manually install the files stored on these Solaris packages elsewhere and patch/fix them to make the whole work. I did that already.
Finally, don't underestimate the willingness of the system administrator to help.
As long as the binary doesn't try to do something that requires superuser privileges and the binary is compiled for your platform, you should be ok.
Related
This is sort of related to a previous post of mine. I have the need to use the bigmemory library on my 32bit Windows PC to do some ugly matrix calculations. Unfortunately, it appears that the maintainers have temporarily ceased production of Windows binaries. I have Ubuntu on my home PC. I would really like to take the .tar.gz file and build it into a Windows binary that I can actually run at work. I realize there are more efficient ways, like installing RTools on the Windows device. However, our IT keeps our admin rights on lockdown, so I can never edit my PATH enviro variable. Could anyone provide some general guidance for doing this? Are there any tools I need to install on my Ubuntu PC above and beyond R?
I found similar questions, but nothing that thoroughly answered my questions.
Unless the package source is incompatible with current versions of R, you could use the R project's win-builder site to build a Windows binary. Quoting from the linked site, win-builder is a service:
intended for useRs who do not have Windows available for checking and building Windows binary packages.
As a convenience, Hadley Wickham's devtools package includes a utility function, build_win(), that you can use for this purpose. From ?build_win:
Works by building source package, and then uploading to http://win-builder.r-project.org/>. Once building is complete you'll receive a link to the built package in the email address listed in the maintainer field. It usually takes around 30 minutes.
Windows has four sets of environment variables (system, user, volatile and process sets). The first three sets are stored in the registry but the process set is not so even if they have locked down the registry its typically still possible to set the process environment variables (including the PATH) in a local process, i.e. on a temporary basis, so you might double check your assumptions that you can't modify anything. Its more likely that you can't modify the system variables and registry but can still modify the set in your local process. To check this from the Windows cmd line enter this:
set mytest=123
set mytest
and if the second line shows that mytest has the value 123 then you likely have all the permissions you need.
Furthermore anything you need to set is all handled automatically for you by R.bat in the batchfiles distribution so you don't have to set anything yourself.
Just ensure that Rtools and R are installed into the standard locations (you can tell them to skip the setting of any registry keys during the installation process), ensure R.bat is on your path or in current directory and run:
R.bat CMD INSTALL mypackage.tar.gz
without setting environment variables, registry keys or path.
If that does not work try Rpathset.bat also from the batchfiles which is not automatic like R.bat but on the other hand is extremely flexible since you must modify the SET statments in it to whatever you want.
There is a PDF document that comes with the batchfiles which gives more info.
I currently have a Java application packaged in an RPM that gets built for 32-bit RedHat platforms, and I want to create a 64-bit RPM, which is largely just the same as the 32-bit one, but with a couple different .so files included. All the Java stuff is the same on both platforms, so it's just JNI .so's.
My question is: Is it possible to have rpmbuild on a 32-bit system generate both the 32-bit and 64-bit RPMs (from different .spec files) since it's just repackaging already-built components, or do I need to build the 64-bit RPM on a 64-bit system?
N.B. I'm not actually building anything native on the system. I'm just repackaging stuff that's already built.
... or vice versa, can I build a 32-bit one on a 64-bit system? I really would prefer just to build and package this on one system than have two separate builds run for the separate RPMs.
As Aaron stated you can build an RPM for multiple distros on the same machine (64-bit), but you have to be very careful or you can run into issues. The biggest problem I've run into is you build on RHEL 5, then you try to deploy to RHEL 6, since RHEL 6 has a different version of RPM installed, it can cause conflicts and fail to install. So in this scenario you have a few options:
Build the RPM on two machines, you've stated you don't really want to do this.
If you have the disk space, configure Mock, I've used it a ton before and it's really easy to get going as long as you have the disk space and the package spec was designed to pull in requires properly.
Personally I'd give Mock a shot, it's quite simple to set up, and will allow you to do what you want with minimal effort as long as the proper repos are available. In the event the build fails the log is pretty comprehensive regarding what the RPM build error was.
From my limited experience in linux, I find a lot of 3rd party programs are installed by default to:
/opt
One program in particular, torque, installs by default to:
/var/spool/torque
I can override this with
./configure --with-server-home=/opt/torque
Is there any reason I should leave the default install directory alone, and not move it to
opt/torque?
I want someone who knows linux best practices to suggest where they think I should install it.
Update
I've researched File Hierarchy Standards (FHS). It seems like /opt and /var/opt are both valid locations for installing programs. I'd still like to know what is considered 'best practice' or even the most common location for installing applications.
There is more than one 'correct' place to install programs.
According to the Filesystem Hierarchy Standards, user programs are frequently installed to /opt/ or /usr/local
While there is nothing wrong with /var/spool/torque as your install directory, it does not follow the FHS.
This actually depends. If the program is a spooler then its installing in the correct location (that is var/spool). If not, then you should change it.
Also about opt vs var/opt generally in modern systems, the root directories (/run,/opt etc) and their "var" counterparts (/var/run,/var/opt) are treated as equal, and in many distros they are actually linked to one another.
So its pretty much your choise. Personally i choose to install under /var because many servers have it mounted on a different disk for data security and redundancy and i would like to make their life easier!
Ok, I know SML/NJ has a self-installing windows .msi.
Unfortunately, I can't install it in my office Windows machine as the strict security policy and I don't want to argue with those IT staff for giving me permissions.
So, can I install SML/NJ without the installer, maybe some zip I can get and just uncompress it for the sml.exe?
Sure. I've put up a build of SML/NJ for Windows in that form at:
http://people.cs.uchicago.edu/~larsberg/smlnj.zip
To use it, unzip it to someplace like the desktop and then, in a command prompt (or globally) do:
set SMLNJ_HOME=c:\Users\USERNAME\Desktop\smlnj
You should then be able to run sml.bat. Feel free to shoot me questions personally if you run into anything; I am the maintainer of the Windows version of SML/NJ.
In a nutshell, the question is: I just finished my first application using Qt Creator on a computer running under Linux Ubuntu, now how do I make this available for everyone. Now follows the more detailed version ;)
I must apologize for asking this, I am aware that this question has probably been asked many times and that there is official documentation that I can read. I am just completely new to programming and I am very confused by everything I've read so far. If you are kind enough to help, please assume I know absolutely nothing :)
Here we go: I've just finished designing my first application (a scientific program) with Qt creator on my laptop which runs under Linux Ubuntu. It works fine and I'm very proud of it ;)
Here's what my project consists of: 40 header files, 42 source files, 1 pro file, 1 qrc file, 1 html file and 7 png files. In the code, I use #include for a bunch of fairly standard Qt classes (QWidget, QTextBrowser and so forth, maybe like 40 of those).
Now I'd like to make it available to other people. For Linux and Mac users, I've figured a way to do that: I can compress the folder containing my project, tell them to install Qt on their computer, then download and extract the files on their hard disk, open a terminal in the folder and run
qmake myProject.pro
qmake
make
That seems to work fine (by the way, does it matter that this is not precisely what Qt creator does? The qmake step there is qmake-qt4 myProject.pro -r -spec linux-g++ and the make step is make -w). Now, I assume there is a solution where I don't ask them to download and install something like 200Mo of Qt material. As for Microsoft Windows users, I don't have a clue.
I would be very grateful if you could explain to me in a very concrete way what I need to do. Needless to say, I'll go for the best and easiest solution, I don't need to understand everything about deployment. Many thanks in advance!
Edit: In case that's useful : I've been using Qt Creator 2.5.0 based on Qt 4.8.1 (64 bit), I'm working on a laptop with Ubuntu 12.04 64bits
For Linux and Mac users, I would compile the software for them in 32 and 64bit formats - no-one likes compiling unknown software from source. Obviously keep the source code option for those on more unusual architectures/OSs (and provide a shell script for them that mimics the commands Qt Creator calls!). As Qt runtimes are available from package managers on just about every distro (and come pre-installed on most anyway, KDE requires them for example), by not asking them to compile from source your users will have a much smaller download (if any) and won't require them to download software from a website potentially unknown to them. Of course the best way would be to try to get your software added as a package into the major distros' repositories, but that may take some time to organise.
Compile your software for Windows users for both 32 and 64bit formats. It's generally frowned upon to ask users to download runtime libraries they potentially don't know, and put them into their system32 folder... So most applications bundle all the libraries they need with their application. Qt-based applications are no different, and so put the runtimes into the folder where the executable is. Also it is much more professional to create a proper installer, there are a few free installer applications for Windows, a web search will give you the most popular (I think I saw a thread on SO about it as well).
As you can see the platforms aren't too dissimilar, the main point I would make is: Do not force people to compile from source! The vast majority of people on Earth do not even know what compiling is, so provide for the major arrchitectures/OSs yourself.