Module installation varies when compared to Windows and linux/Unix Operating system.
In Win32 we need to use a program called nmake and after we follow
1. C:\> perl Makefile.PL
2. C:\> nmake
3. C:\> nmake test
4. C:\> nmake install
and in Linux we follow
1. $ perl Makefile.PL
2. $ make
3. $ make test
4. $ make install
the process of installing would be same for both the operating systems, the only difference would be in the keyword used make and nmake. Could any one let me know what does the letter n represents and what is its specification in windows.
From Wikipedia,
Microsoft nmake, commonly available on Windows. It is fairly basic in
that it offers only a subset of the features of the other two versions
of Make (BSD and GNU ). Microsoft's nmake is not to be confused with
nmake from AT&T and Bell Labs for Unix.
Microsoft nmake is detailed here and GNU make is detailed here
Actually, module installation is usually done as follows on Windows and linux:
cpan Module::Name
On to your question.
Perl expects the same compiler suite that was used to build Perl to be used to build the module.
There are two primary tool chains on Windows. There is the one provided by Microsoft and there is a port of GNU's.
The make tool provided by Microsoft is named nmake.
The make tool provided by the MinGW port of GNU's tools is named dmake.
So,
If your Perl was built using MS's tools (e.g. Windows builds of Perl by ActiveState), you need to to use nmake.
If your Perl was built using GNU's tools (e.g. builds of Perl by Strawberry), you need to to use dmake.
Which brings us back to cpan Module::Name.
cpan will ask Perl what tools were used to build it, and use those tools.
Normally. That's not the case on Windows. cpan is actually far more flexible on Windows. cpan will first look the tool chain that was used to build Perl. If it's not found, cpan install the GNU tool chain for you and temporarily fool perl into believing it was built using GNU's tool chain.
That means you run cpan Module::Name it should work no matter what on ActivePerl. (And there's also ppm install Module::Name, although I'd run ppm with no arguments first to add repositories (e.g. bribes))
Related
I have a C project with a Makefile, I want to build it on windows. I downloaded GNU Make installed. And I have VS2010. The make file has UNIX commands like cc, nvcc and g++. I have to replace them with MS C, CUDA and C++ compilers right? What are the command line commands I have to replace them with? Is there anything I need to install?
I want to do it without Cygwin (it's installation is taking forever), otherwise Cygwin is the fallback method.
You don't actually have to replace any of those commands with the Windows-variant. A working compiler will still compile source code just fine even if it isn't the defacto compiler for an operating system.
I hear ya on the Cygwin bit--you can just install a Minimal GNU environment using MinGW and that'll give you everything that you need to be able to the utilize the Unix makefile.
What is the process to manually installing Perl modules on Windows XP? I've seen UNIX commands like
perl Makefile.PL
make
make install
but I can't find a comparable 'make' command in Windows commandline. I cannot use CPAN to install the modules, as firewall settings prevent the network accesses needed. Any help is greatly appreciated.
Strawberry Perl includes dmake which, to my knowledge, is essentially the same as make except it's built for a Windows environment. There are also other alternatives such as GNU make.
Nowadays Strawberry Perl includes gmake tool.
Trying to use dmake outputs DMAKE WARNING: Do not use dmake.exe utility as it is no longer part of Strawberry Perl, use gmake.exe instead!
Building perl 5.14.2 on windows - getting error NMAKE : fatal error U1077: miniperl.exe' : return code '0x1' while the following command is invoked after running "nmake -logo" from win32 folder under perl source.
../miniperl.exe -I../lib ../make_ext.pl "MAKE=nmake -nologo" --dir=../cpan --dir=../dist --dir=../ext --nonxs
Did anybody face this problem before? Please let me know
Unlike Mac and Unix, Windows doesn't' come with a C compiler installed. Thus, it can be difficult to figure out exactly where things are going wrong without more information. For example, did you install the GCC compiler or another standard C compiler?
The easiest way to get the most recent and complete version of Perl on Windows is to use one of the two standard Windows distributions:
Straberry Perl
ActivePerl
Many people like Strawberry Perl because it's a duplicate of what you find on Unix. The same modules, the same libraries. Others prefer ActivePerl because it includes by default all of the special Windows modules that you probably want to use on Windows to do things like update the registry, talk to the Windows domain to check credentials, etc.
The truth is that both of these versions are more or less the same. The two main complaints of why you should use one over the other:
Strawberry Perl doesn't work with Win32
Active Perl uses PPM and not CPAN.
Are both not correct. You can install and download the Win32 modules in Strawberry Perl and it'll run about every script that ActivePerl does.
And, Active Perl can now install the same C compiler Strawberry Perl uses if you want to install a module that requires compilation. The directions are online. It works with almost all the CPAN modules.
So, unless you have a special reason to build Perl from scratch, I recommend you just download ActivePerl or Strawberry Perl -- especially if you are not really familiar with C/C++ and Make.
Alright, I'm looking into doing a multi-language project. I'm looking at part of that being in Ada. I'm already aware of the AdaCore packages, but I would need to link each file separately, meaning it would probably be easiest to go straight through GCC.
The only problem is that GNAT is apparently mostly written in Ada and I can't seem to find a guide on how to install it anywhere.
MinGW took care of a few of the other languages for me, but apparently GNAT wasn't included in that.
Thanks in advance!
If you later decide to install MinGW Ada, you can update your existing installation using the mingw-get command, shown below, e.g. mingw-get install ada. More details may be found here.
An alternative compiler has its uses, as suggested in this related answer.
$ mingw-get --help
Manage MinGW and MSYS installations (command line user interface).
Usage:
mingw-get [OPTIONS] ACTION [package-spec ...]
mingw-get update
mingw-get [OPTIONS] {install | upgrade | remove} package-spec ...
mingw-get [OPTIONS] {show | list} [package-spec ...]
Options:
--help, -h Show this help text
--version, -V Show version and licence information
Actions:
update Update local copy of repository catalogues
list, show List and show details of available packages
install Install new packages
upgrade Upgrade previously installed packages
remove Remove previously installed packages
Package Specifications:
[subsystem-]name[-component]:
msys-bash-doc The 'doc' component of the bash package for MSYS
mingw32-gdb All components of the gdb package for MinGW
Use 'mingw-get list' to identify possible package names
and the components associated with each.
Addendum: On Windows XP, I piped mingw-get list through grep to pare the list.
$ mingw-get list | grep -i ada
...
Package: mingw32-gcc-v3-ada Subsystem: mingw32
The GNU Ada Compiler
This package provides the MinGW implementation of the GNU Ada language
written in the Ada language.
...
$ gnatmake --version
GNATMAKE 4.5.2
Copyright (C) 1995-2010, Free Software Foundation, Inc.
...
I uploaded the 64bit GNU ada on SF.NET within the Mingw-w64 project.
Go to AdaCore’s Libre site, download the installer and run it!
That said, I think you’re going to have a problem with your scheme of compiling your source files individually; Ada code has to support elaboration, which isn’t something you’d want to manage by hand. I haven’t checked it myself (I don’t program on Windows if I can help it), but here is some information on using GNAT with Windows; worth a look.
Stuff like Ada Web Server requires Ada developer to have a unix-like environment even on Windows so I always install MSYS together with GNAT GPL. There are several guides on how to use MSYS together with MinGW. The only problem is that recent MSYS automated installer is by default configured to use non-AdaCore MinGW which is not what we want.
The latest normal (non-automated) installer of MSYS is here:
http://sourceforge.net/projects/mingw/files/MSYS/Base/msys-core/msys-1.0.11/MSYS-1.0.11.exe/download
After installation you will be asked for MinGW location. Write c:/GNAT/2012 or whatever you use for GNAT (without bin).
On Windows Seven this script failed for unknown reason, but connecting MSYS and MinGW is as simple as writing
c:/GNAT/2012 /mingw
into C:\msys\1.0\etc\fstab
I have cygwin on windows through which I run gcc. But after creating .exe files, if I run them on other computers which dont have cygwin, it says cygwin1.dll not found. Is there a way to compile them so that they run on any system?
You need to compile for MinGW (Minimal GNU Win32) mode. You do that by either installing mingw instead of (or in addition to) cygwin, or by passing the --mno-cygwin compiler option to the cygwin gcc.
In your case, try to copy cygwin1.dll as well (but it could depend on other DLLs as well) (of course you must comply with Cygwin's license with regards to distributing cygwin1.dll)
In cygwin, you can always check the needed modules using:
objdump -p a.exe | grep 'DLL Name'
OR
cygcheck ./a.exe
or for windows in general, use something like this tool: Dependency Walker
You can try compiling with the command line option -mno-cygwin.
See the Cygwin FAQ.
From http://cygwin.com/faq/faq.html#faq.programming.win32-no-cygwin
How do I compile a Win32 executable that doesn't use Cygwin?
The compilers provided by the mingw-gcc, mingw64-i686-gcc, and mingw64-x86_64-gcc packages link against standard Microsoft DLLs instead of Cygwin. This is desirable for native Windows programs that don't need a UNIX emulation layer.
This is not to be confused with 'MinGW' (Minimalist GNU for Windows), which is a completely separate effort.