I have Cygwin, setup version 2.8473, 64-bit. I've installed gcc-g++. I am trying to install SDL2, trying both SDL2-2.0.3 and SDL2-2.0.4. I'll talk about the problems with 2.0.3, since that's the stable release.
I read that I should run /usr/bin/set-gcc-default-3.sh, but it's not there. (gcc does seem to have been installed, as I see it working when I run make in the SDL2-2.0.3 directory.) I haven't been able to find out where to get it by searching Internet -- maybe this is it? Without it, make gives me these complaints:
Warning, configure.in is out of date
and lots of "static declaration" errors like this:
.../SDL_render_d3d11.c:135:19: error: static declaration of 'IID_IDXGIFactory2' follows non-static declaration
static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, 0xe072, 0x4c48, { 0x87, 0xb
^
I wasn't able to find anything useful googling IID_IDXGIFactory2.
According to the SDL Wiki's page on installation, "As of SDL 2.0.3, the codebase still compiles on Cygwin and MingW32, but we expect these to stop working in the future." So it's no longer supported, and I'll leave it.
When loading the Graphics module in the toplevel, I get an error saying "Cannot find graphics.cma".
I'm using OS X and I'm pretty sure I've installed OCaml correctly since I've been using it for about a month now. So it seems that the Graphics module wasn't included in the OCaml package.
How can I fix this issue, or how can I install the Graphics module myself?
First of all, check Graphics is really installed. This library is optional and therefore it may not be installed. There are several ways to check but the following should work for any situation:
$ ls `ocamlc -where`/graphics*
If there is no file listed by the above command, Graphics is not installed and you have to reinstall OCaml compiler enabling Graphics.
If files like graphics.cma are there, then you have to show us how you try to compile your code with Graphics. The best answer varies depending on how you compile: inside toplevel, hand compiling with ocamlc, or with some build tool like ocamlbuild.
The solution mostly depends on how are you compiling. If you're using ocamlbuild tool, the the following would be sufficient:
ocamlbuild -use-ocamlfind -pkg graphics my_program.native
Where my_program.native is your target. Note, you can try to omit the -use-ocamlfind flag.
In order to bring graphics to your toplevel, the easiest solution would be to use topfind:
# #use "topfind";;
# #require "graphics";;
I'm experimenting a problem with the interaction between the ghc-mod plugin in emacs, and NixOS 14.04. Basically, once packages are installed via nix-env -i, they are visible from ghc and ghci, recognised by haskell-mode, but not found by ghc-mod.
To avoid information duplication, you can find all details, and the exact replication of the problem in a VM, in the bug ticket https://github.com/kazu-yamamoto/ghc-mod/issues/269
The current, default, package management set up for Haskell on NixOS does work will with packages that use the ghc-api, or similar (ghc-mod, hint, plugins, hell, ...) run time resources. It takes a little more work to create a Nix expression that integrates them well into the rest of the environment. It is called making a wrapper expression for the package, for an example look at how GHC is installed an operates on NixOS.
It is reasonable that this is difficult since you are trying to make a install procedure that is atomic, but interacts with an unknown number of other system packages with their own atomic installs and updates. It is doable, but there is a quicker work around.
Look at this example on the install page on the wiki. Instead of trying to create a ghc-mod package that works atomically you weld it on to ghc so ghc+ghc-mod is an atomic update.
I installed ghc+ghc-mod with the below install script added to my ~/.nixpkgs/nixpkgs.nix file.
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
# add more packages here
]);
Install package with something like:
nix-env -i hsEnv
or better most of the time:
nix-env -iA nixpkgs.haskellPackages.hsEnv
I have an alias for the above so I do not have to type it out every time. It is just:
nixh hsEnv
The down side of this method is that other Haskell packages installed with nix-env -i[A] will not work with the above installation. If I wanted to get everything working with the lens package then I would have to alter the install script to include lens like:
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
self.lens
# add more packages here
]);
and re-install. Nix does not seem to use a different installation for lens or ghc-mod in hsEnv and with the ghc from nix-env -i ghc so apparently only a little more needs to happen behind the scenes most of the time to combine existing packages in the above fashion.
ghc-mod installed fine with the above script but I have not tested out its integration with Emacs as of yet.
Additional notes added to the github thread
DanielG:
I'm having a bit of trouble working with this environment, I can't even get cabal install to behave properly :/ I'm just getting lots of errors like:
With Nix and NixOS you pretty much never use Cabal to install at the global level
Make sure to use sandboxes, if you are going to use cabal-install. You probably do not need it but its there and it works.
Use ghcWithPackages when installing packages like ghc-mod, hint, or anything needs heavy runtime awareness of existing package (They are hard to make atomic and ghcWithPackages gets around this for GHC).
If you are developing install the standard suite of posix tools with nix-env -i stdenv. NixOS does not force you to have your command line and PATH cultured with tools you do not necessarily need.
cabal assumes the existence a few standard tools such as ar, patch(I think), and a few others as well if memory services me right.
If you use the standard install method and/or ghcWithPackages when needed then NixOS will dedup, on a package level (If you plot a dependency tree they will point to the same package in /nix/store, nix-store --optimise can always dedup the store at a file level.), many packages automatically unlike cabal sandboxes.
Response to comment
[carlo#nixos:~]$ nix-env -iA nixos.pkgs.hsEnv
installing `haskell-env-ghc-7.6.3'
these derivations will be built:
/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv
building path(s) `/nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3'
building /nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
builder for `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed with exit code 2
error: build of `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed
It is the line that starts with collision that tells you what is going wrong:
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
It is a conflict between two different haddocks. Switch to a new profile and try again. Since this is a welding together ghc+packages it should not be installed in a profile with other Haskell packages. That does not stop you from running binaries and interrupters from both packages at once, they just need to be in their own name space so when you call haddock, cabal, ghc, there is only one choice per profile.
If you are not familiar with profiles yet you can use:
nix-env -S /nix/var/nix/profiles/per-user/<user>/<New profile name>
The default profile is either default or channels do not which one it will be for your set up. But check for it so you can switch back to it later. There are some tricks so that you do not have to use the /nix/var/nix/profiles/ directory to store you profiles to cut down on typing but that is the default location.
I'm trying to do the initial work to get our dev shop to start using vagrant + puppet during development. At this stage in my puppet manifest development, I need to install several RPMs that are available via an internal http server (not a repo) with very specific flags ('--nodeps').
So, here's an example of what I need to install:
http://1.2.3.4/bar/package1.rpm
http://1.2.3.4/bar/package2.rpm
http://1.2.3.4/bar/package3.rpm
I would normally install them in this way:
rpm --install --nodeps ${rpm_uri}
I would like to be able to do something like this
$custom_rpms = [
'http://1.2.3.4/bar/package1.rpm',
'http://1.2.3.4/bar/package2.rpm',
'http://1.2.3.4/bar/package3.rpm',
]
# edit: just realized I was instantiating the parameterized
# class wrong. :)
class { 'custom_package': package_file => $custom_rpms }
With this module
# modules/company_packages/manifests/init.pp
define company_package($package_file) {
exec { "/bin/rpm --install --nodeps ${package_file} --nodeps" }
}
But, I'm not sure if that's right. Can some of you puppet masters (no pun intended) school me on how this should be done?
You may have already worked around this by now, but if not.
Using a repository is the preferred method as it will autoresolve all the dependancies, but it that's not available you can try the following. (I'm using epel as an example rpm)
package {"epel-release":
provider=>rpm,
ensure=>installed,
install_options => ['--nodeps'],
source=>"http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm",
}
It used to be that 'install_options ' was only supported in windows.
It appears that it is now supported in linux.
If there is sequence that would be helpful, add "require=Package["package3.rpm"]," to sequence.
Answered by Randm over irc.freenode.net#puppet
Create or use an existing repo and install them with yum so that it resolves the dependencies for you.
A recent question here on SO got me thinking.
On most Linux distributions that I tried, some Perl modules would be available through the package manager. Others, of course, not. For quite a while I would use my package manager whenever I needed to install some CPAN module to find out whether a package was available or not and to install it when it was.
The obvious advantage is that you get your modules updated whenever a new version of the package becomes available.
However, you get in trouble when the module is not available in pre-packaged form and there are dependencies for that module that are. Firing up your package manager every time the cpan shell asks whether it should follow a dependency can be quite tiring.
Often, another drawback is the version of the pre-packaged module. If you are running Debian or Ubuntu you will soon find out that you will not be able to live on the bleeding edge, like many CPAN module authors seem to do.
How do other Perl people on Linux handle that problem? Do you just ignore what your package managers have to offer? Are there any tools that make apt (for example) and cpan better team mates? Or do you simply not install anything via the cpan shell?
For development, I install my own Perl and leave the system Perl alone. If I want to upgrade the system Perl, I use the system package manager. For my development Perl, I use the cpan tool.
Since I keep those separate, I should never mess up the Perl that the system needs for its maintenance tasks and so on, but I don't have to rely on the system's decisions for development.
It's very easy to install separate Perls. When you run Configure from the source distribution, it will ask you where you want to install everything. Give it any path that you like. I have many Perls installed in /usr/local/perls, for instance, and everything for each installation lives separately. I then make symlinks in /usr/local/bin for them (e.g. perl5.8.9, perl.5.10.0, perl5.10.0-threaded). When I want a particular version, I just use the one I want:
$ perl5.10.0 program.pl
The particular binary ensures that the program picks up the right module search path and so on (it's the same stuff in the Config.pm module for that binary).
Here's a script I use to create the symlinks. It looks in the bin directory, figures out the Perl version, and makes links like cpan5.10.1 and so on. Each program already knows the right perl to call:
#!perl
use 5.010;
use strict;
use warnings;
use File::Basename;
use File::Spec::Functions;
my $perls_directory = catfile(
$ARGV[0] // '/usr/local/perls',
'perl*'
);
die "$perls_directory does not exist!\n"
unless -d dirname $perls_directory;
my $links_directory = $ARGV[1] // catfile( $ENV{HOME}, 'bin' ); #/
die "$links_directory does not exist!\n" unless -d $links_directory;
foreach my $directory ( glob( $perls_directory ) )
{
say "Processing $directory...";
unless( -e catfile( $directory, 'bin' ) )
{
say "\tNo bin/ directory. Skipping!";
next;
}
my #perls = glob( catfile( $directory, qw( bin perl5* ) ) );
my( $perl_version ) = $perls[0] =~ m/(5\.\d+\.\d+)\z/;
say "\tperl version is $perl_version";
foreach my $bin ( glob( catfile( $directory, 'bin', '*' ) ) )
{
say "\tFound $bin";
my $basename = basename( $bin );
my $link_basename = do {
if( $basename =~ m/5\.\d+\.\d+\z/) { $basename }
else { "$basename$perl_version" }
};
my $link = catfile( $links_directory, $link_basename );
next if -e $link;
say "\t\tlinking $bin => $link";
symlink $bin => $link or
warn "\t\tCould not create symlink [$!]: $bin => $link!";
}
}
Everything gets install in the right place for that particular Perl.
I've also been thinking that I should put those Perl directories under some sort of source control. If I add a module I don't like, I just back out to an earlier revision. I'm only starting to do that though and haven't played with it much.
I've written more about this sort of thing in the Effective Perler blog:
Make links to per-version tools.
Manage your Perl modules with Git.
We install everything via the CPAN shell. This does ignore what package managers have to offer, but it avoids the headaches you mention when trying to work with them (firing for dependencies, using correct versions).
In addition, it means that our packages can be built programatically (or manually via the shell) on any platform where CPAN runs. Having a dependency on a package manager would affect your ability to distribute your software to platforms that don't use/support that package manager.
Since this question was originally asked, perlbrew has been released. It makes installing custom, self-contained perl installs trivial. And switching between those versions is just as easy:
perlbrew switch $version
I am using Debian for development, and production, and rely on debian Perl packages that are provided with the distro.
For cases where I need a Perl module that is not available in debian, I usually create my own debian package of it and install it.
Ofcourse, this method is not without faults, as a a lot of debian perl modules are outdated (at least in the current debian stable version - etch), and backporting something like Catalyst which has lots of dependencies is not practical.
However, by relying on the OS package manager, I retain all the great features of it, which bring easy maintenance, especially for deployed servers, as you know exactly what packages are installed, and a simple apt-get update;apt-get upgrade (from debian, or from a local repository) upgrades all servers to the same state, including the Perl modules.
I do the following on all my boxes:
I compile my own perl: I still use 5.8.[89] mostly, the stock 5.10.0 has a performance regression that hits me a lot, waiting for 5.10.1 to try again;
I use (and strongly recommend) the local::lib module to keep a module directory per project. Right now, that directory is rsync'ed to all the servers where the project is installed, but I'm testing using git instead;
I create a Task:: module for each project, so that I can install all dependencies with a single command.
I also use the cpan shell and local::lib.
You shouldn't need a Task:: for each project. Just use Module::Install (I like to use Module::Starter like this:
$ module-starter --mi --module=Module::Name --author="Me" --email=me#cpan.org
and then just pop your dependencies in requires 'module::dependency'; in the Makefile.PL. Finally when it's install time, you just perl Makefile.PL (answer yes) then make installdeps
[edit 5 years on from when I gave this answer originally]
These days perlbrew and cpanm are the things to use. local::lib still has a use-case, but the combination of perlbrew and cpanm solve a superset of those cases. Use local::lib when you're not prepared to compile your own perl.
I recommend use only cpan. The modules includes in Linux distro is only to cover package dependency. When you are installing linux without internet access with only CDs, it can't use cpan, so some modules are included as packages, but to a Perl developer this is bad.
Also I used to have a cpan configured to install modules in my home, (.perl) without root login needed.
For production:
In development, choose a version of the perl module which seems right for the requirements; if possible choose the target OS's shipped version (this makes most of the following superfluous), otherwise, pick another one. Create a RPM spec file for it. Use the clean build VM to build the RPM in a reproducable way (from a specfile / source checked in on the appropriate branch).
When the final build can be built (after merge), do the same build from the release branch, commit generated RPMs into deployment repository. This will be used in final validation and then released to production by being copied to the production repository.
All servers in production use the exact same binary that has been fully tested; they use the same spec file and source as the developer intended.
Perl modules are NOT upgraded by any process which does not follow this model. Nor is any other production software.
I use FreeBSD ports and wrap up all the CPAN dependencies in a "meta port" as a sort of a local port. FreeBSD has quite a large number of CPAN modules and their build system is approachable enough that you can easily write your own port if it doesn't exist--just dont forget to submit said port so it gets included in the ports tree. If the port doesn't have the current version in stock, you can always edit the Makefile for the port so it uses the new version, again don't forget to submit the change :-).
Lastly, I use Tinderbox to build the whole mess as binary packages that I then install on the all the production and development machines.
Bottom line--Once you get over your phobia of editing Makefiles, FreeBSD's ports are a great way to maintain your perl application and its dependencies.
I have started using Gentoo recently and Gentoo has a few very important advantages in this area. The first is that g-cpan is capable usually of installing many (though not all) modules from CPAN as Gentoo packages natively, though updating becomes a bit of a problem.
Usually on Gentoo, my approach is to use g-cpan to create an ebuild file, then install from that, tweaking if necessary. The advantage is that upgrading becomes really easy. I then move the file from g-cpan/perl to dev-perl and put it in an overlay for others to use. This allows me to quickly handle the cases g-cpan does not and gentoo packaging is a breeze anyway/