Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: local::lib & multiple architectures

by moritz (Cardinal)
on Dec 05, 2011 at 10:18 UTC ( #941815=note: print w/ replies, xml ) Need Help??


in reply to local::lib & multiple architectures

I haven't tested it, but it should be safe to install both i386 and x86_64 modules to the same local::lib dir.

In my installation (using perlbrew instead of local::lib), pure perl modules are directly under lib/$version/, but XS modules are under lib/$version/x86_64-linux/, so there should be no conflict.


Comment on Re: local::lib & multiple architectures
Select or Download Code
Re^2: local::lib & multiple architectures
by sundialsvc4 (Monsignor) on Dec 05, 2011 at 13:52 UTC

    /me nods... ... but, on the other hand ...

    Many packages in Perl are actually compiled in-place, and as such, they could be quite dependent upon their surroundings.   Whether a particular external DLL or .so exists, exactly what one was linked-in, and so on.   So, what I think that I’d do, instead, is to make a build on an actual representative i386 system, and then clone that to the i386 systems as needed.   I’d feel a whole lot more confident about that.

      Many packages in Perl are actually compiled in-place, and as such, they could be quite dependent upon their surroundings.

      Compiled in-place? You mean they override themselves during compilation? I've never encountered that.

      If not, could you maybe elaborate on what you mean by "compiled in-placed"? Are you talking about dynamic linking?

        What I mean is that, if you watch a great many packages in the process of being installed, you see a C or C++ compiler running.   This is how the dynamic-link libraries are constructed:   they’re not downloaded in binary form, but built on-the-spot.

        Therefore, I suggest that, if you’re going to deploy an application and its packages onto a particular target, you maybe ought to (if possible) actually build your master-copy on a “typical” example of exactly that target system.   Now you have a plausible reason to expect that, whatever dependency there might be upon “the surroundings,” those “surroundings” will be the same.   To me, that is the approach that is least likely to produce unwanted phone calls at two o’clock in the morning.   :-)   I am therefore suggesting that “what I would choose to do is...” to create a 64-bit master copy for my 64-bit machines, and a 32-bit master copy for my 32-bit machines.   (After ensuring of course that all of them are maintained at identical operating-system service levels.)

        A deployed app can easily involve dependencies on hundreds of library modules, any one of which could have XS-modules involved, therefore any one of which could cause unexpected phone-calls in the night.   Hence, build two deployments, one for each target, and separately “test the hell out of them on that very target.”   Replicate out to each production system from the appropriate master, then run post-deployment self tests on each production machine (automatically).   That is my “wish-list scenario,” and it’s one that I personally would push very hard to achieve.   ’Cuz when I’m asleep, (almost...) the only thing I want to wake me up is the dawn.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://941815]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2014-09-17 06:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (60 votes), past polls