My problem is that when running install.sh for the PacsOne installation on Max OSX 10.8.2 Mountain Lion, the install.sh script does not find the required library tool glibtool. It is my understanding that glibtool is actually GNU's libtool, but Apple renames this as "glibtool" because Apple's libtool is different. Apple used to include glibtool with Xcode, yet has discontinued this practice. Thus, when I run the PacsOne install.sh, glibtool is not found.
I also understand that it is possible to build GNU's libtool on Mac OSX, and I have ftp'ed GNU's libtool, autoconf, automake and m4.
When trying to configure GNU's libtool, I get an error message that gcc can not create executables. I am not sure at this point if that error involves gcc wanting to compile Objective C on a Mac, or if there is a problem with the loader.
My questions are:
Has anyone else had these issues that can give me a tip on how to proceed with a successful installation of PacsOne?
Is there an easier way to get the required glibtool that PacsOne's install.sh wants to use?
Can Xiaohui help to point me in the right direction?
I appreciate your help!
Installation of PacsOne on Mac OSX 10.8.2 Mountain Lion
Have you tried downloading the libtool package for Mac OS X:
http://mac.softpedia.com/progDownload/l ... 27313.html
Read the README file after extracting that package for instructions on how to build it on Mac OS X.
http://mac.softpedia.com/progDownload/l ... 27313.html
Read the README file after extracting that package for instructions on how to build it on Mac OS X.
Thanks. I did finally get this installation to work... ironically, just a few minutes before receiving your reply.
I downloaded libtool from GNU and built it on the Mac, prefixed to /usr/local
I altered the install.sh to use /usr/local/bin/libtool, rather than ask for "which glibtool" -- since Apple does not supply glibtool anymore.
I symlinked /usr/lib/libfreetype.dylib and /usr/bin/mysql to use the corresponding paths in /Applications/MAMP/Library/.
For the mysql socket location, I entered /Applications/MAMP/tmp/mysql/mysql.sock
And then the installation worked.
I hope that this post helps anyone that is trying to install PacsOne on a Mac. It's more than simply a matter of typing the command:
./install.sh
A person performing the PacsOne installation on a Mac will need to make several modifications to get the installation to work.
I downloaded libtool from GNU and built it on the Mac, prefixed to /usr/local
I altered the install.sh to use /usr/local/bin/libtool, rather than ask for "which glibtool" -- since Apple does not supply glibtool anymore.
I symlinked /usr/lib/libfreetype.dylib and /usr/bin/mysql to use the corresponding paths in /Applications/MAMP/Library/.
For the mysql socket location, I entered /Applications/MAMP/tmp/mysql/mysql.sock
And then the installation worked.
I hope that this post helps anyone that is trying to install PacsOne on a Mac. It's more than simply a matter of typing the command:
./install.sh
A person performing the PacsOne installation on a Mac will need to make several modifications to get the installation to work.
PacsOne v6.3.5 on Mountain Lion v10.8.2
authenion,
Have you successfully launched the PacsOne v6.3.5 on Mountain Lion v10.8.2?
I have most of the component working but the ImageMagick does not work.
I have copied the imagick.so to /usr/libexec/apache2/ & put the extension_dir=/usr/libexec/apache2/ in the /private/etc/php.ini but its not working at all.
When I execute php -i | grep eaccelerator I get the following warning
$ php -i | grep eaccelerator
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/libexec/apache2/imagick.so' - dlopen(/usr/libexec/apache2/imagick.so, 9): no suitable image found. Did find:
/usr/libexec/apache2/imagick.so: mach-o, but wrong architecture in Unknown on line 0
PHP Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in Unknown on line 0
Your help will be highly appreciated....
Thanks,
Have you successfully launched the PacsOne v6.3.5 on Mountain Lion v10.8.2?
I have most of the component working but the ImageMagick does not work.
I have copied the imagick.so to /usr/libexec/apache2/ & put the extension_dir=/usr/libexec/apache2/ in the /private/etc/php.ini but its not working at all.
When I execute php -i | grep eaccelerator I get the following warning
$ php -i | grep eaccelerator
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/libexec/apache2/imagick.so' - dlopen(/usr/libexec/apache2/imagick.so, 9): no suitable image found. Did find:
/usr/libexec/apache2/imagick.so: mach-o, but wrong architecture in Unknown on line 0
PHP Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for 'CST/-6.0/no DST' instead in Unknown on line 0
Your help will be highly appreciated....
Thanks,
I did this installation of PacsOne on a Mac remotely via a TeamViewer session on the behalf of my boss, who was too busy to do this installation, so I helped him out. Although I have worked extensively with PacsOne as a software engineer for nearly 3 years, about 99% of that work was done on Linux. This was my first PacsOne installation.
After the PacsOne installation was completed on the Mac, the TeamViewer session was reset and I do not have access to that machine to investigate the ImageMagick issues that you refer to. But I am confident that everything is running fine on that Mac (or I may have been called back to assist).
I noticed that a lot of the location-specific items that the PacsOne installer complained about, I was able to remedy using an symbolic link in the directory where PacsOne expected to find that item -- linking it to wherever it happened to be. I think that for any PHP extension library, you need those under /usr/lib/php/modules/ (on Linux), yet for a Mac running MAMP, those PHP extensions are somewhere else, like for example extension_dir = "/Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/"
(That's where PHP extensions are on my local machine, a MacBook Pro.)
My basic approach in the PacsOne installation on the remote Mac (which was a Mac Mini running Mountain Lion and MAMP Pro) was to leave all the MAMP-related files where they were (to keep MAMP happy) and then symlink the locations where the PacsOne installer expected them to be, to the locations where those files actually were. Then the PacsOne installer was happy, and ran through the installation without any problems.
I think that the apache modules are installed in their own directory, and the PHP extension modules are installed in their own, separate directory. On Linux, those are: /usr/lib/httpd/modules/ and /usr/lib/php/modules/
On MAMP (my MacBook), the PHP extension directory is as mentioned above, and my apache modules are stored in the directory you found (/usr/libexec/apache2/).
I am not sure if your Mac is running MAMP or if all the apache, mysql, and PHP components have been installed independently... but... you probably do not want to point the PHP extension dir to the apache extension dir within your php.ini. Basically, you want everything set up on the Mac the way that MAMP expects, and create symlinks in the Mac filesystem to keep the PacsOne installer happy. PacsOne likes everything set up the way it is on Linux, so you have to symlink the Mac so that it appears more Linux-like to the PacsOne installer. If you are not using MAMP, then it is still the same general idea... find out where PacsOne installer expects to find everything, then make it look that way. Don't change your php.ini file, but symlink to please PacsOne. If you point things to the wrong place in php.ini, it is likely to break PHP.
My basic tool was to use the locate command to find out where things were... uh... located. I compared that with the error messages I was getting from PacsOne installer, and also by looking at the text of the installer script. Then I symlinked. I think I only needed to hack the installer script to change one or two paths. I did not change php.ini.
I had taken extensive notes on my PacsOne-on-Mac install, but unfortunately, my note taking app has obliterated them... so I am just going on memory. And I can't go back and look at that machine, because I don't have access anymore. But hopefully, these comments are helpful to you.
After the PacsOne installation was completed on the Mac, the TeamViewer session was reset and I do not have access to that machine to investigate the ImageMagick issues that you refer to. But I am confident that everything is running fine on that Mac (or I may have been called back to assist).
I noticed that a lot of the location-specific items that the PacsOne installer complained about, I was able to remedy using an symbolic link in the directory where PacsOne expected to find that item -- linking it to wherever it happened to be. I think that for any PHP extension library, you need those under /usr/lib/php/modules/ (on Linux), yet for a Mac running MAMP, those PHP extensions are somewhere else, like for example extension_dir = "/Applications/MAMP/bin/php/php5.3.6/lib/php/extensions/no-debug-non-zts-20090626/"
(That's where PHP extensions are on my local machine, a MacBook Pro.)
My basic approach in the PacsOne installation on the remote Mac (which was a Mac Mini running Mountain Lion and MAMP Pro) was to leave all the MAMP-related files where they were (to keep MAMP happy) and then symlink the locations where the PacsOne installer expected them to be, to the locations where those files actually were. Then the PacsOne installer was happy, and ran through the installation without any problems.
I think that the apache modules are installed in their own directory, and the PHP extension modules are installed in their own, separate directory. On Linux, those are: /usr/lib/httpd/modules/ and /usr/lib/php/modules/
On MAMP (my MacBook), the PHP extension directory is as mentioned above, and my apache modules are stored in the directory you found (/usr/libexec/apache2/).
I am not sure if your Mac is running MAMP or if all the apache, mysql, and PHP components have been installed independently... but... you probably do not want to point the PHP extension dir to the apache extension dir within your php.ini. Basically, you want everything set up on the Mac the way that MAMP expects, and create symlinks in the Mac filesystem to keep the PacsOne installer happy. PacsOne likes everything set up the way it is on Linux, so you have to symlink the Mac so that it appears more Linux-like to the PacsOne installer. If you are not using MAMP, then it is still the same general idea... find out where PacsOne installer expects to find everything, then make it look that way. Don't change your php.ini file, but symlink to please PacsOne. If you point things to the wrong place in php.ini, it is likely to break PHP.
My basic tool was to use the locate command to find out where things were... uh... located. I compared that with the error messages I was getting from PacsOne installer, and also by looking at the text of the installer script. Then I symlinked. I think I only needed to hack the installer script to change one or two paths. I did not change php.ini.
I had taken extensive notes on my PacsOne-on-Mac install, but unfortunately, my note taking app has obliterated them... so I am just going on memory. And I can't go back and look at that machine, because I don't have access anymore. But hopefully, these comments are helpful to you.