OS X client will not run with 64 bit Perl

[Scott Hannahs]

The darwin-perl-lib files are all i386 or ppc7400 binaries. The native PERL in OSX 10.6 is 64 bit (X86_64) and cannot call 32 bit libraries. The following files need to be compiled with the X866_64 flag as an architecture. It is unclear if the ppc7400 type binary will run on all ppc systems and should be the generic ppc architecture instead.

The offending files are SSLeay.bundle, Compress.bundle, Crypt/SSLeay.bundle and Expat.bundle

The final application is built as a 32 bit as well but since it is calling PERL I *think* it is ok. But changing that compile option should be trivial.

The problem is that perl5.10.0 on OSX 10.6.6 crashes. It is crashing in
/Applications/OCSNG.app/Contents/Resources/lib//auto/Net/SSLeay/SSLeay.bundle which is the one bundle that seems to have x86_64 architecture!!! ??

I have attached the crash log.

-Scott

% find darwin-perl-lib -perm +0111 -type f -exec file \{\} \;
darwin-perl-lib/auto/Net/SSLeay/SSLeay.bundle: Mach-O universal binary with 4 architectures
darwin-perl-lib/auto/Net/SSLeay/SSLeay.bundle (for architecture ppc7400): Mach-O bundle ppc
darwin-perl-lib/auto/Net/SSLeay/SSLeay.bundle (for architecture ppc64): Mach-O 64-bit bundle ppc64
darwin-perl-lib/auto/Net/SSLeay/SSLeay.bundle (for architecture i386): Mach-O bundle i386
darwin-perl-lib/auto/Net/SSLeay/SSLeay.bundle (for architecture x86_64): Mach-O 64-bit bundle x86_64
darwin-perl-lib/darwin-thread-multi-2level/auto/Compress/Raw/Zlib/Zlib.bundle: Mach-O universal binary with 2 architectures
darwin-perl-lib/darwin-thread-multi-2level/auto/Compress/Raw/Zlib/Zlib.bundle (for architecture i386): Mach-O bundle i386
darwin-perl-lib/darwin-thread-multi-2level/auto/Compress/Raw/Zlib/Zlib.bundle (for architecture ppc7400): Mach-O bundle ppc
darwin-perl-lib/darwin-thread-multi-2level/auto/Crypt/SSLeay/SSLeay.bundle: Mach-O universal binary with 2 architectures
darwin-perl-lib/darwin-thread-multi-2level/auto/Crypt/SSLeay/SSLeay.bundle (for architecture i386): Mach-O bundle i386
darwin-perl-lib/darwin-thread-multi-2level/auto/Crypt/SSLeay/SSLeay.bundle (for architecture ppc7400): Mach-O bundle ppc
darwin-perl-lib/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle: Mach-O universal binary with 2 architectures
darwin-perl-lib/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle (for architecture i386): Mach-O bundle i386
darwin-perl-lib/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle (for architecture ppc7400): Mach-O bundle ppc

[mortheres (mortheres)]

Hi Scott,

Thanks a lot for your report. Yes, the bundle files you specify are compiled to support only i386 and ppc 7400 architecture. I don't have a MacOSX 64 bits to test it or recompile the files :( :(.

If you have Xcode and and a little bit of courage, can you try to regenerate the embedded CPAN tree with your 64 bits MacOSX computer to see if it solves the problem ? You can generate the CPAN module tree using the script 'create-darwin-perl-lib_fromCPAN.pl' which is in the tools/macosx/scripts directory of the OCS Unix agent sources. This script will generate the tarball 'macosx-perl-lib-dep-snapshot.tar.gz' which corresponds to the Resources/lib/ tree in OCSNG.app.

From my part, I will take a look to see if there is an easy way to specify the architectures in CPAN compilation options.

Kind regards

Guillaume

[Scott Hannahs (shannahs)]

I tried. I followed the information in that script, but my system does not work in building the Sys::MacProfile module. This has some dot files that are left over resource forks that break CPAN.

I know that Daniel was working on a complete rework version 0.4 of the module but I haven't heard about progress in about a year. I will ping him and see if I can get a progress report.

Possibly update my CPAN? It says it is out of date and maybe a newer verison will ignore all the resource forks in the CPAN module?

So update CPAN to the latest version. Change the destination to the new folder. Run the script. Change the destination back. I am not a perl expert and not sure where all these files get stored.

-Scott

[mortheres (mortheres)]

Hi,

I had the same problems too when I tried to install Mac::Sysprofile from CPAN :( :(. So, yes if you have contacts with Daniel, it is a good idea to get news about the 0.4 version.

If you followed the comments at the begin of the darwin-perl-lib_fromCPAN.pl script, all the Perl modules the script installs are stored in a directory named "darwin-perl-lib" in your user directory. This prevent to install Perl modules at system side and this make easier to create the tarball file after installing the modules using the script.

For your tests, you can disable the Mac::Sysprofile inztallation by deleting the line which begin by "Mac::Sysprofile" (line 99) in the darwin-perl-lib_fromCPAN.pl script. Mac::Sysprofile won't be compiled but the goal of these test is to solve the 64 bits architecture problems with bundle files. We will solve the Mac::Sysprofile problem later.

Kind regards,

Guillaume

[Scott Hannahs (shannahs)]

I believe that the sequence I described worked. The only glitch was that the --ssl libraries did not get built so I added them manually.

cpan CPAN
<change config to make new darwin-perl-lib directory>
perl scripts/create-darwin-perl-lib_fromCPAN.pl --install --ssl
cpan Crypt::SSLeay
cpan Net::SSLeay
<change PERL config to use default directory>
mv ~/darwin-perl-lib/ .
sh BUILDME.sh
sh scripts/create_install_wrapper.sh

However the daemon seems to quit without a message. It shows that it is launched in "debug" mode and the log file gets to
[Wed Apr 20 18:19:31 2011][debug] [download] Calling download_start_handler
[Wed Apr 20 18:19:31 2011][debug] - Net::SSLeay qw(die_now die_if_ssl_error) loaded
[Wed Apr 20 18:19:31 2011][debug] Compress::Zlib is available.

and then just stops.
./ocsinventory-agent --local ~ --force --debug
creates an ocs file in my home directory as I expect but if I try to direct it to the server.

% sudo -u ocsng ./ocsinventory-agent --server ocsinventory-ng.magnet.fsu.edu --force --debug
Can't locate HTTP/Config.pm in @INC (@INC contains: /Applications/OCSNG.app/Contents/Resources/lib/ /Library/Perl/Updates/5.10.0 /System/Library/Perl/5.10.0/darwin-thread-multi-2level /System/Library/Perl/5.10.0 /Library/Perl/5.10.0/darwin-thread-multi-2level /Library/Perl/5.10.0 /Network/Library/Perl/5.10.0/darwin-thread-multi-2level /Network/Library/Perl/5.10.0 /Network/Library/Perl /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level /System/Library/Perl/Extras/5.10.0 .) at /Applications/OCSNG.app/Contents/Resources/lib//LWP/UserAgent.pm line 746.

This seems it imply that not all the Perl modules got built by the script. I guess I can try going through the list of modules in the script and installing each one and seeing which ones don't get installed correctly but something is wrong with the CPAN script. It would be nice if that script did changed the CPAN defaults as well.

Cheers,
Scott

[Scott Hannahs (shannahs)]

I think I have found a problem. The create-darwin--lib_fromCPAN.pl script has hardwired into it the installation of G/GA/GAAS/libwww-perl-5.813.tar.gz. However on MacOSX 10.6 the default perl is 5.10 and not 5.8. This may be a problem? Or am I confusing Perl Versions and module versions.

Further it seems that this library is installed by CPAN LWP ?? Should it be needed in the list at all?

[Scott Hannahs (shannahs)]

Not sure, I am at a lost. I have as many CPAN libraries installed as I can from the script and the log gets to

[Mon Apr 25 15:05:11 2011][debug] Turns hooks on for /etc/ocsinventory-agent/modules.conf
[Mon Apr 25 15:05:11 2011][debug] Ocsinventory unified agent for UNIX, Linux and MacOSX 2.0rc3
[Mon Apr 25 15:05:11 2011][debug] Log system initialised (File)
[Mon Apr 25 15:05:11 2011][debug] Calling handlers : `start_handler'
[Mon Apr 25 15:05:11 2011][debug] [download] Calling download_start_handler
[Mon Apr 25 15:05:11 2011][debug] - Net::SSLeay qw(die_now die_if_ssl_error) loaded
[Mon Apr 25 15:05:11 2011][debug] Compress::Zlib is available.

And then the process quits.

[mortheres (mortheres)]

Hi Scott,

The agent stops after the log message or it continues its inventory ? Is it just the download process that stops ?
Try to disable Donwload.pm module by commenting the line in /etc/ocsinventory-agent/modules.conf to see if the agent is able to do its standard inventory.

Thanks a lot for your tests :) :).

Kind regards,

Guillaume

[Scott Hannahs (shannahs)]

It seems to stop after the message since nothing has been reported to the server. I don't see anything executing.

If I disable the downloads module it still stops in the same place

[Tue Apr 26 22:12:09 2011][debug] Account info updated successfully
[Tue Apr 26 22:12:09 2011][debug] Time to call Proc::Daemon
[Tue Apr 26 22:12:09 2011][debug] Daemon started
[Tue Apr 26 22:12:09 2011][debug] Proc::PID::File available, checking for pid file
[Tue Apr 26 22:12:10 2011][debug] OCS Agent initialised
[Tue Apr 26 22:12:10 2011][info] Going to sleep for 99 second(s)
[Tue Apr 26 22:13:49 2011][debug] Turns hooks on for /etc/ocsinventory-agent/modules.conf
[Tue Apr 26 22:13:49 2011][debug] Calling handlers : `start_handler'
[Tue Apr 26 22:13:49 2011][debug] Compress::Zlib is available.

[Gonéri Le Bouder (goneri)]

Hi,

Actually it's not just about the CPU arch. The OS version is important too or you will get segfault for every ABI changes. That's why for FusionInventory, we decided to build a full perl tree for every OS version. We, FusionInventory developers, fixed a lot of MacOSX issue and we generate clean packages:
http://prebuilt.fusioninventory.org/stable/

I wounder if we can collaborate together on this instead of spending time recreating the while. BTW, you can pick our patches if you think they are useful.

Best regards,

[Scott Hannahs (shannahs)]

@Gonéri, Yes there is the problem of different Perl builds on different OS systems. At the moment I am just trying to get it to build and run on a OS X 10.6.X systems. I will try to see what needs to be done for compatibility with Perl 5.8.8 and Perl 5.10.0. Maybe they do need completely different libraries and that will be a drag but the installer can be made more intelligent. I am hoping that changes to the OS will not cause segfaults every time, or if so very seldom.

However, a full perl tree install internal to the inventory program seems like a bit of a big footprint for something such as an inventory program. I would like the inventory program to be as light weight as possible both in terms of CPU, space etc. But it may be necessary eventually.

I will look again at fusion inventory. BUT, this is not my decision, but one that was asked by our Computer Support Group to install OCSInventory on our Macs. Moving to FusionInventory is a possibility but I don't know the real reasons for the forking of the inventory project from OCS to Fusion Inventory. As the naive user this seems to be an added incompatibility with possible problems down the road.

I certainly don't want to re-invent the wheel and at the moment there are compatibilities between the systems. But I am not sure about future proofing that capability as we move down the road map for each system. If the agents are to be compatible then why are there two projects? If there are different visions for the future of the agent then this is a problem for future proofing and compatibility. Trying to pick the patches from one project and applying them to another and then debugging between two different maintainers seems to be a bigger task than I want to take on with my limited perl programming capabilities.

I will try the fusioninventory agent and see what I can do with the default install.

[mortheres (mortheres)]

Hi,

I am agree with Scott because it is not conceivable that we embeed a complete Perl tree inside the agent. We don't want that OCS agent become a fatty agent. In the worst case, we could effectively build a package per Macosx and architecture version with specific modifications but not with the complete Perl tree inside the packages.

However, we will take a look on what have been done in Fusioninventory to see if it could be useful for OCS agent.

Guillaume

[mortheres (mortheres)]

Hi,

The x86_64 bits support for OCSNG.app and Perl modules has been integrated in revision 1058 of the ocsinventory-unix-agent/stable-2.0 branch : http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-unix-agent/trunk/revision/1058.

It have been integrated in the new OCS MacOSX agent 2.0 beta1 release :) :).

Kind regards,

Guillaume