I understand that making the Dynlibs themselves binary compatible would be unsolvable given the fragmentation of the targets, but I wonder if there isn't the possibility of an intermediary solution.

Assuming that the required libraries existed on the target system, the information needed for the perl runtime to invoke them could be embedded in a system specific library. 'scuse me if the following descriptions are somewhat clumsy or dumbed down, but I found it difficult to describe in generic terms.

For a stand-alone Perl app to invoke a DynLib routine it needs, and has available to it, essentially 4 pieces of information.

• The name of the library
• The name of the routines
• The order, types and values of the parameters to pass.
• The order and types of values to be returned.

The information missing at this level are

• The locations of the libraries
• The calling conventions of the library routines (C, Fortran, other).
• The byte ordering of the parameters and return values.

It seems to me that you could have a piece of interface code that accepted the information that the interpreter knows in the (a) standard format and massaged them in a locally specific manner in order to call the DynLib and then retrieve the return(s) and pass them back to the interpreter. This piece of code could be pretty small and made available and a public library of binary versions for most systems could then be added to cpan or elsewhere and wouldn't take a lot of space. This would be a part of the same archive as the binary runtime interpreters.

This would still require local libraries to be built for any given target system by the owner/operators of that system, but should give enough isolation from local specifics to allow genericity of distributable binary applications?

Now you confuse me. If the local libraries can be assume to be there, what is the problem you are trying to solve?

Abigail

I see three reasons for wanting the "standalone executable" referred to in this thread.

• Avoiding the need to distribute source code with applications.
• Avoiding the start-up costs associated with re-compiling the source for every run.
• Avoiding need to build and install perl on every machine that is to run that application.

Being able to capture and encapsulate the bytecode along with a binary bytecode interpreter addresses the first two.

Allowing that bytecode to use DynLibs goes a long way to addressing the third part of the equation. Making those Dynlibs available without the need to rebuild them on every machine completes it.

Whilst it would be a huge logistical problem to make all the cpan modules available in binary form for all possible target systems, most organisations have only one or two flavours of workstation or server available. Requiring them to build the DynLibs for their own target systems avoids the storage and licencing issues associated with doing this from a central super-corporate location like cpan. They could then choose to locate copies of these DynLibs either locally or on the network.

I appreciate that they could make the perl interpreter available via nfs or similar, but the need to pull everything across the network, interpret it each time a script is used causes a huge run-time penalty.

Allowing pure perl modules to be used in their bytecode form, would vastly reduce this runtime hit. The only fly in that ointment (that I see) is, as you pointed out, non-Perl extensions. These are the Dynlib parts that would need to be built locally.

Under this scheme Perl would consist of several parts.

Development time source compiler with embedded runtime interpreter. Capable of running an application from source as now, also capable of spitting out a platform-independant bytecode 'image' of the application. This could consist of either just the 'application code' or that application code plus the bytecode for any pure perl module dependancies controlled by a switch. In either form, it would contain the fix-up information required to call binary DynLib dependancies through the platform specific interface module described earlier.

The runtime perl would consist of a platform specific binary bytecode interpreter with the interface module built-in. It would be possible to invoke this and point it at one of the bytecode applications, and it would run much as now.

I would also be possible to 'attach' an applications bytecode to a binary runtime and turn it into a platform specific binary application. This would still invoke the Dynlibs via the interface module, but would ease the packaging and distribution.

In corporate terms, the ability to distribute applications to workstations and servers in bytecode form, whilst not completly preventing localised tinkering, would make it sufficiently hard that it would prevent it from being casually done. This would, in and of itself, be worthwhile.

For the small software developer, it would allow the development of saleable application programs in markets that don't want to concern themselves with compliers and sourcecode management. They might also need to zip the application up with the appropriate platform specific binary libraries, but this is SOP for developers in these markets as exemplified by the VB runtime libraries.

There are undoubtably still holes in my argument, but I don't see any show stoppers other than the resistance of status quo.

I saw your comments elsewhere regarding the quality of the new breed of Perl programmer, and in some ways understand them, but I don't think keeping perl the exclusive domain of ....I'll let you choose your own phrase here... would be to the benefit of Perl in the long run. I could be wrong on that, but LW seems pretty determined to ensure that Perl remains accessible to the newcomer and I have no reason to challenge that.

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.