|
Posted by Clyde Ingram on December 30, 2004, 7:16 pm
Please log in for more thread options
I am experimenting with GD.pm, installed on a PC running Windoze XP, using
ActiveState PPM (in Perl 5.8.6 -- 811), like this:
ppm install http://theoryx5.uwinnipeg.ca/ppms/GD.ppd
This outputs a trace list of files that it loads on my PC:
====================
Install 'GD' version 2.19 in ActivePerl 5.8.3.809.
====================
Successfully installed GD version 2.19 in ActivePerl 5.8.3.809.
Installing E:PerlsitelibautoGDGD.dll
Installing E:PerlsitelibautoGDGD.lib
Installing E:PerlsitelibautoGDGD.exp
Installing E:PerlsitelibautoGDGD.bs
Installing E:Perlhtmlbinbdf2gdfont.pl.html
Installing E:Perlhtmlbinbdf2gdfont.html
Installing E:PerlhtmlsitelibGD.html
Installing E:PerlhtmlsitelibGDSimple.html
Installing E:PerlhtmlsitelibGDPolyline.html
Files found in blibarch: installing files in bliblib into architecture
dependent library tree
Installing E:Perlsitelibqd.pl
Installing E:PerlsitelibGD.pm
Installing E:PerlsitelibautoGDautosplit.ix
Installing E:PerlsitelibGDPolyline.pm
Installing E:PerlsitelibGDSimple.pm
Installing E:Perlbinbdf2gdfont.bat
Installing E:Perlbinbdf2gdfont.pl
How can I "package" up GD for installation on other machines which I am not
allowed to connect ot the Internet?
For example, onto a development Windoze NT 4.0 platform, or a production
Windoze 2003 server?
Does registering for an ASPN profile, and using the PPM "profile" command
help me here?
Ultimately, I will want to install GD.pm on Solaris 2.6 and 2.8 develpment
and production servers, which also have no Internet connection.
But, judging by the pain in loading GD.pm on Windoze, Solaris is going to be
even tougher.
Thank-you for any guidance in this area.
Clyde
|
|
Posted by Sherm Pendley on December 30, 2004, 4:51 pm
Please log in for more thread options
Clyde Ingram wrote:
> How can I "package" up GD for installation on other machines which I am not
> allowed to connect ot the Internet?
....
> Ultimately, I will want to install GD.pm on Solaris 2.6 and 2.8 develpment
> and production servers, which also have no Internet connection.
> But, judging by the pain in loading GD.pm on Windoze, Solaris is going to be
> even tougher.
Don't know how to do it with PPM, but on *nix with the traditional make
file builds, it's quite simple. When you do your "make install" step,
specify a destination directory other than the final location, like this:
make install DESTDIR=/tmp/GD_module
That prefixes the location of every file to be installed with DESTDIR,
so a file that would be installed in /usr/local/lib/perl5 will instead
be installed to /tmp/GD_module/usr/local/lib/perl5, and so on.
After the dust settles it's easy to make a tarball from the package
directory, that you can then copy to the target machine and unpack at
the root level. Tar makes that easy by storing relative pathnames in
archives by default. On the build machine:
cd /tmp/GD_module
tar czvf GD_module.tgz *
Then, on the target machine:
cd /
tar xzvf GD_module.tgz
The DESTDIR option is specifically intended for packagers - I've used it
successfully to produce binary packages for GD and a number of other
Perl modules for Mac OS X.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
|
|
Posted by Jacob on January 10, 2005, 3:33 pm
Please log in for more thread options Hi Folks and especially Sherm.
I'm new to this group but Sherm's reply to Clyde seemed to be the
answer to my problem: Installing perl, DBI and DBD on a [production]
system where they don't want to install a compiler. (Licensing
issues.) So I installed perl on a development system with a
compiler. In the final step, I used the command:
make install DESTDIR=/work_pmdd/oracle/p_archive/perl.5.8.6
and, sure enough, a whole /usr/local/bin hierarchy appears below the
$DESTDIR directory. At my liesure I could tar this, FTP it to the
production system and have the SA untar it. (I though he would have
to run a make install on the target machine but that's another
bridge to jump off.)
Following Sherm's advice, I did the same for the DBI:
make install DESTDIR=/work_pmdd/oracle/p_archive/DBI-1.46
Yes, the directory exists and yes, the "make install" was run as
root. But this DESTDIR directory remains stubbornly empty. This
does not bode well for the DBD install.
So what could have gone kerbosh? And more important, where it is? I
went looking for a "bin" directory someplace under the directory
where I ran all the MAKE commands - where the PERL stuff was
untarred - but it just ain't there.
So how do I get a tar-able diectory structure of he DBD and DBD
(from which I expect the same grief)?
I'm open to ideas here..
-- Jacob Salomon (JSalomon at bn.com)
Sherm Pendley wrote:
>Clyde Ingram wrote:
>
>>How can I "package" up GD for installation on other machines which
>>I am not allowed to connect ot the Internet?
>
>...
>
>>Ultimately, I will want to install GD.pm on Solaris 2.6 and 2.8
>>develpment and production servers, which also have no Internet
>>connection. But, judging by the pain in loading GD.pm on Windoze,
>>Solaris is going to be even tougher.
>
>Don't know how to do it with PPM, but on *nix with the traditional
>make file builds, it's quite simple. When you do your "make
>install" step, specify a destination directory other than the final
>location, like this:
>
> make install DESTDIR=/tmp/GD_module
>
>That prefixes the location of every file to be installed with
>DESTDIR, so a file that would be installed in /usr/local/lib/perl5
>will instead be installed to /tmp/GD_module/usr/local/lib/perl5,
>and so on.
>
>After the dust settles it's easy to make a tarball from the package
>directory, that you can then copy to the target machine and unpack
>at the root level. Tar makes that easy by storing relative
>pathnames in archives by default. On the build machine:
>
> cd /tmp/GD_module
> tar czvf GD_module.tgz *
>
>Then, on the target machine:
> cd /
> tar xzvf GD_module.tgz
>
>The DESTDIR option is specifically intended for packagers - I've
>used it successfully to produce binary packages for GD and a number
>of other Perl modules for Mac OS X.
>
>sherm--
|
|
Posted by Sherm Pendley on January 10, 2005, 7:11 pm
Please log in for more thread options Jacob wrote:
> make install DESTDIR=/work_pmdd/oracle/p_archive/perl.5.8.6
>
> and, sure enough, a whole /usr/local/bin hierarchy appears below the
> $DESTDIR directory. At my liesure I could tar this, FTP it to the
> production system and have the SA untar it. (I though he would have
> to run a make install on the target machine but that's another
> bridge to jump off.)
No "make install" should be needed on the target machine, just untar it. If
you create the tarball with:
cd /work_pmdd/oracle/p_archive/perl.5.8.6
tar czvf perl5.8.6.tgz *
You should get a tarball with relative paths. Then the SA could just do the
following:
cd /
tar xzvf /path/to/perl5.8.6.tgz
> Following Sherm's advice, I did the same for the DBI:
>
> make install DESTDIR=/work_pmdd/oracle/p_archive/DBI-1.46
>
> Yes, the directory exists and yes, the "make install" was run as
> root. But this DESTDIR directory remains stubbornly empty. This
> does not bode well for the DBD install.
Odd - I've done this myself with DBI, DBD::mysql, and DBD::Pg. All worked
just fine.
> So what could have gone kerbosh? And more important, where it is? I
> went looking for a "bin" directory
Are you sure you're looking in the right place? Modules would normally
install under /usr/local/lib, not /usr/local/bin.
Also, when you do this on your development machine, you need to use a Perl
that's configured and installed the same way it will be on your target
machine.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
|
|
Posted by Jacob on January 10, 2005, 5:05 pm
Please log in for more thread options Thanks for the quick reply, Sherm.
Lets take your points one at a time:
Sherm Pendley wrote:
>Jacob wrote:
>
>>make install DESTDIR=/work_pmdd/oracle/p_archive/perl.5.8.6
>>
>>and, sure enough, a whole /usr/local/bin hierarchy appears
>>below the $DESTDIR directory. At my liesure I could tar
>>this, FTP it to the production system and have the SA untar
>>it. (I though he would have to run a make install on the >>target
machine but that's another bridge to jump off.)
>
>No "make install" should be needed on the target machine,
>just untar it. If you create the tarball with:
>
> cd /work_pmdd/oracle/p_archive/perl.5.8.6
> tar czvf perl5.8.6.tgz *
>
>You should get a tarball with relative paths. Then the SA
>could just do the following:
>
> cd /
> tar xzvf /path/to/perl5.8.6.tgz
First off, Sherm, I appreciate your emphatic correction of my
misconception of how to install the binary perl on the target
machine. Your advice sounds like something my SA tried but
without the benefit of the hierarchy added by the DESTDIR
definition.
As for the vanishing DESTDIR for the DBI:
>>Following Sherm's advice, I did the same for the DBI:
>>
>>make install DESTDIR=/work_pmdd/oracle/p_archive/DBI-1.46
>>
>>Yes, the directory exists and yes, the "make install" was
>>run as root. But this DESTDIR directory remains stubbornly
>>empty. This does not bode well for the DBD install.
>
>Odd - I've done this myself with DBI, DBD::mysql, and
>DBD::Pg. All worked just fine.
>
>>So what could have gone kerbosh? And more important, where
>>it is? I went looking for a "bin" directory
>
>Are you sure you're looking in the right place? Modules would
>normally install under /usr/local/lib, not /usr/local/bin.
Of course I'm looking in the right places! The first right
place to look was, of course, the DESTDIR directory; we have
already established that has remained empty. And of course,
the real build left files in /usr/lib, as in the first line of
output (which will overflow the line-break. Sorry):
Installing
/usr/local/lib/perl5/site_perl/5.8.0/aix-thread-multi-64all/auto/DBI/DBIXS.h
I was referring to a usr/local/... hierarchy someplace under
my working directory, /work/oracle/perl/perl-5.8.6. So,
starting one level higher, I now tried finding a directory
named "local" or even usr. Nada.
Of course, it would be nice if Tim B were to see this thread
(I'm reluctant to add bloat to his in-box) and groks a
solution. For now, it looks like we'll have to install the C
compiler, at least temporarily, on the production boxes. I'd
consider that a failure to find the truly correct solution but
I got users waiting.
>Also, when you do this on your development machine, you need
>to use a Perl that's configured and installed the same way it
>will be on your target machine.
The development and production machines are pretty alike
except for the sheer size of the boxes. So the untar at the
prod box should work fine. That is, if I can generate the
blessed TAR files for DBI and DBD.
-- Jacob (JSalomon at bn.com)
|
| Similar Threads | Posted | | Updating installed modules? | June 23, 2006, 3:36 am |
| Finding installed modules | January 8, 2008, 4:52 pm |
| List of all modules installed on a system | August 8, 2007, 1:41 pm |
| install modules error | May 16, 2008, 10:54 pm |
| Howto run pre-install perl modules | December 27, 2004, 2:57 am |
| how to install multiple modules with one Makefile.PL | July 2, 2008, 11:56 am |
| Local install of modules - no root; no telnet | November 9, 2004, 12:54 am |
| Unable to install 'Msql-Mysql-modules' | July 27, 2005, 3:50 am |
| perl upgrade, req to understand which modules to install | October 2, 2006, 2:54 pm |
| What is installed | December 8, 2005, 11:18 am |
|
XML Sitemap