Although it should theoretically be possible to build an entirely static Perl, it might involve an unnecessary amount of tweaking (in particular, if you also want libc to be linked in statically...).   It's probably easier to just upload any required shared libs (see ldd output) together with the perl binary, and then have the environment variable LD_LIBRARY_PATH point to the directory where you're keeping those private libs... (preferably just for the CGI environment, so you don't risk messing up other things - see the apache docs for how to do that).

Update: As to the libc issue I hinted at above, I just remembered I wrote up something in a different forum some time ago. The context is a rather different one (so it's not a recipe on how to link Perl statically), but if you look for the -nodefaultlibs stuff, you'll get an idea of what things you'd have to mess with to get a truly static binary...   - Just in case anyone is interested.

Your "something" looks very useful, thanks! I'm off to try to find a glibc-2.2.4 package; if I can, than I should be able to compile and upload a compatible dynamic perl to the web page.

I tried that first, but the glibc on the server is also ancient, so uploaded dynamic elf's won't run. Will go look at your "something" - thanks.

Considering you've not specified what OS, I'm going to hazard that the answer is "No". Or at least, "Not in any useful form". (Granted you say "dll" which means it's probably Wintendo but that still leaves some variables unbound)

Provide relevant details (i.e. OS, version, compiler) and you might get an answer.

I expect the same in principle to be true of Windows although the make program will be different and so will the make file.

If all you have is FTP access, you probably won't be able to do things like make the file (perl executable) executable as far a linux goes.

Strictly speaking, on Linux, an executable doesn't need to be executable :)  You can always run it directly via the dynamic loader. If you don't believe it, try the following:

Copy the perl binary to some temp directory

$ cp `which perl` /tmp
[download]

Remove the executable bit

$ chmod -x /tmp/perl
$ ls -l /tmp/perl
-rw-r--r-- 1 ab ab 1061700 Apr 20 00:47 /tmp/perl
[download]

Now, if you try to run it normally, you'd of course get

$ /tmp/perl -v
bash: /tmp/perl: Permission denied
[download]

but if you use the dynamic loader, it works without a hitch

$ /lib/ld-linux.so.2 /tmp/perl -v

This is perl, v5.8.8 built for x86_64-linux-thread-multi
(...)
[download]

Also depending on the setup, you could potentially not have access to your rc files (bashrc, cshrc, bash_profile) and would thus be unable to set environment variables needed

You don't necessarily need to. If you have mod_env available, you can conveniently set them from your apache config (e.g. for the CGI directory in question):

SetEnv LD_LIBRARY_PATH /path/to/private/shared/libs
[download]

This even works with .htaccess files, so you don't need write access to the main httpd.conf. Also, as I tried to point out, it's probably not even a good idea to set LD_LIBRARY_PATH system-wide from some rc file (too many side effects if you mess with important libs on that scale...).

almut,

congrats (and ++) ... you just tought an old dog a new trick. 10+ years in UNIX/Linux and I've never seen the ld-linux trick (well i may have but forgotten). i like it, thanks!!

no time to get into the rest ... never tried setting ENV vars in a .htaccess, not saying you're wrong, just never tried it. in a nutshell, my basic argument against the rest of the post is that if bobb doesn't have access enough to do the things suggested, he certainly won't have access to the httpd.conf, apachectl or global LD_LIBRARY_PATH (i know you suggest against it as i would agree). on the .htaccess ENV thing, would that work? the file would be in some user's directory but httpd would most likely not be running as that user. i've never needed to look but this would make sense only if the CGI was executed as the user who owned it, not the user running the httpd process (nobody, daemon whomever).

anyway, thanks for the cool trick and for making me think!!

--marc

Access is convoluted and exasperating, but with patience I can get quite a bit done. Ftp provides "chmod", but not "chown". I can create a cgi script on my home machine, upload it with ftp, make it executable with chmod +x, then browse the script to execute it. I've learned quite a bit about the server, but its perl and glibc are very old, and incompatible with anything I do on my home machine.

My question is not strictly Perl related.

Why do you need to use this server as outdated as it is? If you have a choice, don't.

If the ISP is receptive, ask them to update the server or to move you to one of their updated servers. Many ISPs who will refuse to update a server will be more than willing to move your stuff to a server with a more modern toolset. The reason for this is that they don't want to expose existing customers on existing servers to update issues like language compatibility changes and such. This is a particular issue for PHP, and somewhat for MySQL. It's usually not an issue for Perl but it can be if someone's uploaded binary modules of their own. These ISPs tend to keep the old servers around and do only OS-level security updates on them. When they outgrow capacity, the new servers are built to a newer spec. So when you update a site, asking to be moved to a different server sometimes works when asking for an update to the server you're on will not.

If someone insists that you use that specific server, perhaps you could explain the situation. If those things fail, I guess building your own perl and uploading it is an option. Some ISPs don't allow compiled programs to be uploaded. Some that do allow it don't allow new versions of tools already offered. You should make sure this is acceptable practice on the server if you can get an answer. If the ISP doesn't allow it and you're still under the gun to do the site, you might need to backport to the earlier perl.