[Pharo-project] Building 32-bit Cairo library on Macs
Hello, i'd like to know, if there's anyone who can help with making 32-bit version of cairo library on macs? Because if i just do: port install cairo everything is ok, except that VM cannot use that library because it is 64bit.. And if i set build_arch to "i386" in /opt/local/etc/macports/macports.conf and run it, it also doesn't going well (see the end of mail), because of having too much dependecies from libraries which already installed and 64-bit :( Is there a way to tell port to just build stuff in a separate place.. or is there a way to build cairo library without port? sudo port install cairo Warning: port definitions are more than two weeks old, consider using selfupdate ---> Fetching pkgconfig ---> Attempting to fetch pkg-config-0.25.tar.gz from http://lil.fr.distfiles.macports.org/pkgconfig ---> Verifying checksum(s) for pkgconfig ---> Extracting pkgconfig ---> Applying patches to pkgconfig ---> Configuring pkgconfig ---> Building pkgconfig ---> Staging pkgconfig into destroot ---> Installing pkgconfig @0.25_1 ---> Deactivating pkgconfig @0.23_1 ---> Activating pkgconfig @0.25_1 ---> Cleaning pkgconfig ---> Fetching libpixman ---> Attempting to fetch pixman-0.20.0.tar.bz2 from http://lil.fr.distfiles.macports.org/libpixman ---> Verifying checksum(s) for libpixman ---> Extracting libpixman ---> Configuring libpixman ---> Building libpixman ---> Staging libpixman into destroot ---> Installing libpixman @0.20.0_0 ---> Deactivating libpixman @0.16.4_0 ---> Activating libpixman @0.20.0_0 ---> Cleaning libpixman ---> Fetching xorg-util-macros ---> Attempting to fetch util-macros-1.11.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-util-macros ---> Verifying checksum(s) for xorg-util-macros ---> Extracting xorg-util-macros ---> Configuring xorg-util-macros ---> Building xorg-util-macros ---> Staging xorg-util-macros into destroot ---> Installing xorg-util-macros @1.11.0_0 ---> Deactivating xorg-util-macros @1.5.0_0 ---> Activating xorg-util-macros @1.11.0_0 ---> Cleaning xorg-util-macros ---> Fetching xorg-xtrans ---> Attempting to fetch xtrans-1.2.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xtrans ---> Verifying checksum(s) for xorg-xtrans ---> Extracting xorg-xtrans ---> Configuring xorg-xtrans ---> Building xorg-xtrans ---> Staging xorg-xtrans into destroot ---> Installing xorg-xtrans @1.2.6_0 ---> Deactivating xorg-xtrans @1.2.5_0 ---> Activating xorg-xtrans @1.2.6_0 ---> Cleaning xorg-xtrans ---> Fetching xorg-bigreqsproto ---> Attempting to fetch bigreqsproto-1.1.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-bigreqsproto ---> Verifying checksum(s) for xorg-bigreqsproto ---> Extracting xorg-bigreqsproto ---> Configuring xorg-bigreqsproto ---> Building xorg-bigreqsproto ---> Staging xorg-bigreqsproto into destroot ---> Installing xorg-bigreqsproto @1.1.1_0 ---> Deactivating xorg-bigreqsproto @1.1.0_0 ---> Activating xorg-bigreqsproto @1.1.1_0 ---> Cleaning xorg-bigreqsproto ---> Fetching xorg-xcmiscproto ---> Attempting to fetch xcmiscproto-1.2.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xcmiscproto ---> Verifying checksum(s) for xorg-xcmiscproto ---> Extracting xorg-xcmiscproto ---> Configuring xorg-xcmiscproto ---> Building xorg-xcmiscproto ---> Staging xorg-xcmiscproto into destroot ---> Installing xorg-xcmiscproto @1.2.1_0 ---> Deactivating xorg-xcmiscproto @1.2.0_0 ---> Activating xorg-xcmiscproto @1.2.1_0 ---> Cleaning xorg-xcmiscproto ---> Fetching xorg-xextproto ---> Attempting to fetch xextproto-7.1.2.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xextproto ---> Verifying checksum(s) for xorg-xextproto ---> Extracting xorg-xextproto ---> Configuring xorg-xextproto ---> Building xorg-xextproto ---> Staging xorg-xextproto into destroot ---> Installing xorg-xextproto @7.1.2_0 ---> Deactivating xorg-xextproto @7.1.1_0 ---> Activating xorg-xextproto @7.1.2_0 ---> Cleaning xorg-xextproto ---> Fetching xorg-inputproto ---> Attempting to fetch inputproto-2.0.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-inputproto ---> Verifying checksum(s) for xorg-inputproto ---> Extracting xorg-inputproto ---> Configuring xorg-inputproto ---> Building xorg-inputproto ---> Staging xorg-inputproto into destroot ---> Installing xorg-inputproto @2.0.1_0 ---> Deactivating xorg-inputproto @2.0_0 ---> Activating xorg-inputproto @2.0.1_0 ---> Cleaning xorg-inputproto ---> Fetching xorg-xproto ---> Attempting to fetch xproto-7.0.20.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xproto ---> Verifying checksum(s) for xorg-xproto ---> Extracting xorg-xproto ---> Configuring xorg-xproto ---> Building xorg-xproto ---> Staging xorg-xproto into destroot ---> Installing xorg-xproto @7.0.20_0 ---> Deactivating xorg-xproto @7.0.16_0 ---> Activating xorg-xproto @7.0.20_0 ---> Cleaning xorg-xproto ---> Computing dependencies for xorg-libXdmcp ---> Fetching xorg-libXdmcp ---> Attempting to fetch libXdmcp-1.1.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXdmcp ---> Verifying checksum(s) for xorg-libXdmcp ---> Extracting xorg-libXdmcp ---> Configuring xorg-libXdmcp ---> Building xorg-libXdmcp ---> Staging xorg-libXdmcp into destroot ---> Computing dependencies for xorg-libXdmcp ---> Installing xorg-libXdmcp @1.1.0_0 ---> Deactivating xorg-libXdmcp @1.0.3_0 ---> Activating xorg-libXdmcp @1.1.0_0 ---> Cleaning xorg-libXdmcp ---> Computing dependencies for xorg-libXau ---> Fetching xorg-libXau ---> Attempting to fetch libXau-1.0.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXau ---> Verifying checksum(s) for xorg-libXau ---> Extracting xorg-libXau ---> Configuring xorg-libXau ---> Building xorg-libXau ---> Staging xorg-libXau into destroot ---> Computing dependencies for xorg-libXau ---> Installing xorg-libXau @1.0.6_0 ---> Deactivating xorg-libXau @1.0.5_0 ---> Activating xorg-libXau @1.0.6_0 ---> Cleaning xorg-libXau ---> Computing dependencies for libxml2 ---> Dependencies to be installed: libiconv zlib ---> Fetching libxml2 ---> Attempting to fetch libxml2-2.7.8.tar.gz from http://lil.fr.distfiles.macports.org/libxml2 ---> Verifying checksum(s) for libxml2 ---> Extracting libxml2 ---> Configuring libxml2 Error: You cannot install libxml2 for the architecture(s) i386 because Error: its dependency libiconv only contains the architecture(s) x86_64. Error: Error: Did you upgrade to a new version of Mac OS X? If so, please see Error: Error: http://trac.macports.org/wiki/Migration Error: Error: Target org.macports.configure returned: incompatible architectures in dependencies Log for libxml2 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libxml2/main.log Error: Unable to upgrade port: 1 Error: Unable to execute port: upgrade xrender failed To report a bug, see <http://guide.macports.org/#project.tickets> -- Best regards, Igor Stasenko.
Hi: On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386". Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
2011/11/23 Stefan Marr <pharo@stefan-marr.de>
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Best regards Stefan
I had the same problem with the OpenCV and the mysqlclient libraries that I used through FFI. For OpenCV I found a 32bits precompiled framework on the Web. For mysqlclient, I did exactly what Stefan said i.e. configure universal flavour for both i386 and x86_64 architectures and install (recompile all dependencies) using the universal flag. Luc
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2011/11/23 Stefan Marr <pharo@stefan-marr.de>
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Best regards Stefan
I had the same problem with the OpenCV and the mysqlclient libraries that I used through FFI. For OpenCV I found a 32bits precompiled framework on the Web. For mysqlclient, I did exactly what Stefan said i.e. configure universal flavour for both i386 and x86_64 architectures and install (recompile all dependencies) using the universal flag.
Did you success on using OpenCV through FFI ? I was interested but i bit afraid by the amount of work to have a working prototype. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2011/11/23 Stefan Marr <pharo@stefan-marr.de>
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Best regards Stefan
I had the same problem with the OpenCV and the mysqlclient libraries that I used through FFI. For OpenCV I found a 32bits precompiled framework on the Web. For mysqlclient, I did exactly what Stefan said i.e. configure universal flavour for both i386 and x86_64 architectures and install (recompile all dependencies) using the universal flag.
Did you success on using OpenCV through FFI ? I was interested but i bit afraid by the amount of work to have a working prototype.
it says that 2.1 version is implemented in C++... making calls to C++ through FFI is completely different story, and unfortunately there is no common standard for C++ dynamic libs. Unless it having C API wrapper.
Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
-- Best regards, Igor Stasenko.
On Thu, Nov 24, 2011 at 11:23 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2011/11/23 Stefan Marr <pharo@stefan-marr.de>
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Best regards Stefan
I had the same problem with the OpenCV and the mysqlclient libraries that I used through FFI. For OpenCV I found a 32bits precompiled framework on the Web. For mysqlclient, I did exactly what Stefan said i.e. configure universal flavour for both i386 and x86_64 architectures and install (recompile all dependencies) using the universal flag.
Did you success on using OpenCV through FFI ? I was interested but i bit afraid by the amount of work to have a working prototype.
it says that 2.1 version is implemented in C++... making calls to C++ through FFI is completely different story, and unfortunately there is no common standard for C++ dynamic libs. Unless it having C API wrapper.
Normally in the last version of OpenCV, they combine a C and C++ interfaces at the same time. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
AccesIO does the same thing with their driver DLL/SO; I use their C library for obvious reasons. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Serge Stinckwich [serge.stinckwich@gmail.com] Sent: Wednesday, November 23, 2011 10:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs On Thu, Nov 24, 2011 at 11:23 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2011/11/23 Stefan Marr <pharo@stefan-marr.de>
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Best regards Stefan
I had the same problem with the OpenCV and the mysqlclient libraries that I used through FFI. For OpenCV I found a 32bits precompiled framework on the Web. For mysqlclient, I did exactly what Stefan said i.e. configure universal flavour for both i386 and x86_64 architectures and install (recompile all dependencies) using the universal flag.
Did you success on using OpenCV through FFI ? I was interested but i bit afraid by the amount of work to have a working prototype.
it says that 2.1 version is implemented in C++... making calls to C++ through FFI is completely different story, and unfortunately there is no common standard for C++ dynamic libs. Unless it having C API wrapper.
Normally in the last version of OpenCV, they combine a C and C++ interfaces at the same time. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Sig, There is an oddly similar conversation on the Plplot-devel mailing list: "Unnecessary library linkage". Very likely, it's the Cairo folks who need to read it though. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab@anest.ufl.edu] Sent: Wednesday, November 23, 2011 10:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs AccesIO does the same thing with their driver DLL/SO; I use their C library for obvious reasons. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Serge Stinckwich [serge.stinckwich@gmail.com] Sent: Wednesday, November 23, 2011 10:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs On Thu, Nov 24, 2011 at 11:23 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2011/11/23 Stefan Marr <pharo@stefan-marr.de>
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Best regards Stefan
I had the same problem with the OpenCV and the mysqlclient libraries that I used through FFI. For OpenCV I found a 32bits precompiled framework on the Web. For mysqlclient, I did exactly what Stefan said i.e. configure universal flavour for both i386 and x86_64 architectures and install (recompile all dependencies) using the universal flag.
Did you success on using OpenCV through FFI ? I was interested but i bit afraid by the amount of work to have a working prototype.
it says that 2.1 version is implemented in C++... making calls to C++ through FFI is completely different story, and unfortunately there is no common standard for C++ dynamic libs. Unless it having C API wrapper.
Normally in the last version of OpenCV, they combine a C and C++ interfaces at the same time. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
It depends on how much ++ they used. Sometimes, it is simply a matter of annoying name mangling[*]. In one situation, I had success dumping the exported names and pasting the obvious into the FFI methods. An example: getErrorText:errorCode pBuffer:pBuffer bufferSize:bufferSize type:type "int GetErrorText(int errorCode, char* pBuffer, int bufferSize, enum MESSAGE_TYPE type)" < apicall: long '?GetErrorText@@YAHHPADHW4MESSAGE_TYPE@@@Z' ( long char* long long ) > ^self invalidCall. I was not happy with the vendor. All it takes is extern "C" to avoid the hassle. Bill [*] Yes, I know they call it "decoration" now, but there was a time when men were men, and they wrote compilers that MANGLED names :) ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, November 23, 2011 9:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs On 24 November 2011 02:50, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, Nov 24, 2011 at 1:30 AM, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2011/11/23 Stefan Marr <pharo@stefan-marr.de>
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Best regards Stefan
I had the same problem with the OpenCV and the mysqlclient libraries that I used through FFI. For OpenCV I found a 32bits precompiled framework on the Web. For mysqlclient, I did exactly what Stefan said i.e. configure universal flavour for both i386 and x86_64 architectures and install (recompile all dependencies) using the universal flag.
Did you success on using OpenCV through FFI ? I was interested but i bit afraid by the amount of work to have a working prototype.
it says that 2.1 version is implemented in C++... making calls to C++ through FFI is completely different story, and unfortunately there is no common standard for C++ dynamic libs. Unless it having C API wrapper.
Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/
-- Best regards, Igor Stasenko.
On 23 November 2011 17:08, Stefan Marr <pharo@stefan-marr.de> wrote:
Hi:
On 23 Nov 2011, at 16:50, Igor Stasenko wrote:
build_arch to "i386"
There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386".
Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that.
Aha! sudo port install cairo +universal should do the trick. (building now)
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: Â +32 2 629 3525
-- Best regards, Igor Stasenko.
Sig, I know almost nothing about Macs, but have sometimes cheated my way around 64/32 bit hassles on Linux by using a vm. If you have a choice to force a system to be 32 bit, then you might try that in a vm and build the library there, after which (thinking like a Linux user), you might simply be able to copy the files to your 64 bit OS. This assumes OS X will install as a guest (search results suggest it will). At one point, I followed some instructions to install 32 bit libraries by installing 32 bit firefox on a 64 bit system. Shortly after that, I started simply installing 32 bit systems to avoid the hassles. If I was not the first person to get to a machine<g>, the vm trick provides a home. Of course, Pharo will eventually make all of this irrelevant by giving us seamless integration of the libraries, right?? :) If anyone can do it, you and Stef will make it happen. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, November 23, 2011 10:50 AM To: Pharo Development; The general-purpose Squeak developers list Subject: [Pharo-project] Building 32-bit Cairo library on Macs Hello, i'd like to know, if there's anyone who can help with making 32-bit version of cairo library on macs? Because if i just do: port install cairo everything is ok, except that VM cannot use that library because it is 64bit.. And if i set build_arch to "i386" in /opt/local/etc/macports/macports.conf and run it, it also doesn't going well (see the end of mail), because of having too much dependecies from libraries which already installed and 64-bit :( Is there a way to tell port to just build stuff in a separate place.. or is there a way to build cairo library without port? sudo port install cairo Warning: port definitions are more than two weeks old, consider using selfupdate ---> Fetching pkgconfig ---> Attempting to fetch pkg-config-0.25.tar.gz from http://lil.fr.distfiles.macports.org/pkgconfig ---> Verifying checksum(s) for pkgconfig ---> Extracting pkgconfig ---> Applying patches to pkgconfig ---> Configuring pkgconfig ---> Building pkgconfig ---> Staging pkgconfig into destroot ---> Installing pkgconfig @0.25_1 ---> Deactivating pkgconfig @0.23_1 ---> Activating pkgconfig @0.25_1 ---> Cleaning pkgconfig ---> Fetching libpixman ---> Attempting to fetch pixman-0.20.0.tar.bz2 from http://lil.fr.distfiles.macports.org/libpixman ---> Verifying checksum(s) for libpixman ---> Extracting libpixman ---> Configuring libpixman ---> Building libpixman ---> Staging libpixman into destroot ---> Installing libpixman @0.20.0_0 ---> Deactivating libpixman @0.16.4_0 ---> Activating libpixman @0.20.0_0 ---> Cleaning libpixman ---> Fetching xorg-util-macros ---> Attempting to fetch util-macros-1.11.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-util-macros ---> Verifying checksum(s) for xorg-util-macros ---> Extracting xorg-util-macros ---> Configuring xorg-util-macros ---> Building xorg-util-macros ---> Staging xorg-util-macros into destroot ---> Installing xorg-util-macros @1.11.0_0 ---> Deactivating xorg-util-macros @1.5.0_0 ---> Activating xorg-util-macros @1.11.0_0 ---> Cleaning xorg-util-macros ---> Fetching xorg-xtrans ---> Attempting to fetch xtrans-1.2.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xtrans ---> Verifying checksum(s) for xorg-xtrans ---> Extracting xorg-xtrans ---> Configuring xorg-xtrans ---> Building xorg-xtrans ---> Staging xorg-xtrans into destroot ---> Installing xorg-xtrans @1.2.6_0 ---> Deactivating xorg-xtrans @1.2.5_0 ---> Activating xorg-xtrans @1.2.6_0 ---> Cleaning xorg-xtrans ---> Fetching xorg-bigreqsproto ---> Attempting to fetch bigreqsproto-1.1.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-bigreqsproto ---> Verifying checksum(s) for xorg-bigreqsproto ---> Extracting xorg-bigreqsproto ---> Configuring xorg-bigreqsproto ---> Building xorg-bigreqsproto ---> Staging xorg-bigreqsproto into destroot ---> Installing xorg-bigreqsproto @1.1.1_0 ---> Deactivating xorg-bigreqsproto @1.1.0_0 ---> Activating xorg-bigreqsproto @1.1.1_0 ---> Cleaning xorg-bigreqsproto ---> Fetching xorg-xcmiscproto ---> Attempting to fetch xcmiscproto-1.2.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xcmiscproto ---> Verifying checksum(s) for xorg-xcmiscproto ---> Extracting xorg-xcmiscproto ---> Configuring xorg-xcmiscproto ---> Building xorg-xcmiscproto ---> Staging xorg-xcmiscproto into destroot ---> Installing xorg-xcmiscproto @1.2.1_0 ---> Deactivating xorg-xcmiscproto @1.2.0_0 ---> Activating xorg-xcmiscproto @1.2.1_0 ---> Cleaning xorg-xcmiscproto ---> Fetching xorg-xextproto ---> Attempting to fetch xextproto-7.1.2.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xextproto ---> Verifying checksum(s) for xorg-xextproto ---> Extracting xorg-xextproto ---> Configuring xorg-xextproto ---> Building xorg-xextproto ---> Staging xorg-xextproto into destroot ---> Installing xorg-xextproto @7.1.2_0 ---> Deactivating xorg-xextproto @7.1.1_0 ---> Activating xorg-xextproto @7.1.2_0 ---> Cleaning xorg-xextproto ---> Fetching xorg-inputproto ---> Attempting to fetch inputproto-2.0.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-inputproto ---> Verifying checksum(s) for xorg-inputproto ---> Extracting xorg-inputproto ---> Configuring xorg-inputproto ---> Building xorg-inputproto ---> Staging xorg-inputproto into destroot ---> Installing xorg-inputproto @2.0.1_0 ---> Deactivating xorg-inputproto @2.0_0 ---> Activating xorg-inputproto @2.0.1_0 ---> Cleaning xorg-inputproto ---> Fetching xorg-xproto ---> Attempting to fetch xproto-7.0.20.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xproto ---> Verifying checksum(s) for xorg-xproto ---> Extracting xorg-xproto ---> Configuring xorg-xproto ---> Building xorg-xproto ---> Staging xorg-xproto into destroot ---> Installing xorg-xproto @7.0.20_0 ---> Deactivating xorg-xproto @7.0.16_0 ---> Activating xorg-xproto @7.0.20_0 ---> Cleaning xorg-xproto ---> Computing dependencies for xorg-libXdmcp ---> Fetching xorg-libXdmcp ---> Attempting to fetch libXdmcp-1.1.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXdmcp ---> Verifying checksum(s) for xorg-libXdmcp ---> Extracting xorg-libXdmcp ---> Configuring xorg-libXdmcp ---> Building xorg-libXdmcp ---> Staging xorg-libXdmcp into destroot ---> Computing dependencies for xorg-libXdmcp ---> Installing xorg-libXdmcp @1.1.0_0 ---> Deactivating xorg-libXdmcp @1.0.3_0 ---> Activating xorg-libXdmcp @1.1.0_0 ---> Cleaning xorg-libXdmcp ---> Computing dependencies for xorg-libXau ---> Fetching xorg-libXau ---> Attempting to fetch libXau-1.0.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXau ---> Verifying checksum(s) for xorg-libXau ---> Extracting xorg-libXau ---> Configuring xorg-libXau ---> Building xorg-libXau ---> Staging xorg-libXau into destroot ---> Computing dependencies for xorg-libXau ---> Installing xorg-libXau @1.0.6_0 ---> Deactivating xorg-libXau @1.0.5_0 ---> Activating xorg-libXau @1.0.6_0 ---> Cleaning xorg-libXau ---> Computing dependencies for libxml2 ---> Dependencies to be installed: libiconv zlib ---> Fetching libxml2 ---> Attempting to fetch libxml2-2.7.8.tar.gz from http://lil.fr.distfiles.macports.org/libxml2 ---> Verifying checksum(s) for libxml2 ---> Extracting libxml2 ---> Configuring libxml2 Error: You cannot install libxml2 for the architecture(s) i386 because Error: its dependency libiconv only contains the architecture(s) x86_64. Error: Error: Did you upgrade to a new version of Mac OS X? If so, please see Error: Error: http://trac.macports.org/wiki/Migration Error: Error: Target org.macports.configure returned: incompatible architectures in dependencies Log for libxml2 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libxml2/main.log Error: Unable to upgrade port: 1 Error: Unable to execute port: upgrade xrender failed To report a bug, see <http://guide.macports.org/#project.tickets> -- Best regards, Igor Stasenko.
On 23 November 2011 17:45, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
I know almost nothing about Macs, but have sometimes cheated my way around 64/32 bit hassles on Linux by using a vm. Â If you have a choice to force a system to be 32 bit, then you might try that in a vm and build the library there, after which (thinking like a Linux user), you might simply be able to copy the files to your 64 bit OS. Â This assumes OS X will install as a guest (search results suggest it will).
At one point, I followed some instructions to install 32 bit libraries by installing 32 bit firefox on a 64 bit system. Â Shortly after that, I started simply installing 32 bit systems to avoid the hassles. Â If I was not the first person to get to a machine<g>, the vm trick provides a home.
Of course, Pharo will eventually make all of this irrelevant by giving us seamless integration of the libraries, right?? :) Â If anyone can do it, you and Stef will make it happen.
not before Cog could run on 64bit system. P.S. this port collection is crazy.. it still builds dependencies, including python (OMG), and x11 libs.. for a thing, like cairo library.. so much dependencies.. there is something wrong with linux world.
Bill
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
P.S. this port collection is crazy.. it still builds dependencies, including python (OMG), and x11 libs.. for a thing, like cairo library.. so much dependencies.. there is something wrong with linux world.
Maybe homebrew? I've never used it, but google showed a --build32 flag and "brew install cairo --use-clang" (clang flag needed only for Lion, apparently per https://github.com/mxcl/homebrew/issues/8144) -- View this message in context: http://forum.world.st/Building-32-bit-Cairo-library-on-Macs-tp4100118p410071... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sig, I don't think it's Linux so much as the kinds of things that Alan Kay has observed as being horribly wrong in computer science/engineering education. Produce programmers with zero (if not confused/negative) skills in engineering ("no taste" as Steve Jobs said of MS) and you get really bad software. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, November 23, 2011 12:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs [snip] P.S. this port collection is crazy.. it still builds dependencies, including python (OMG), and x11 libs.. for a thing, like cairo library.. so much dependencies.. there is something wrong with linux world.
Bill
-- Best regards, Igor Stasenko.
nevermind, after multiple painfull upgrade/clean/--enforce-variants and other voodoo dances, i got it installed. Now the question if it will work as expected and can be loaded by 32-bit VM , which is Cog :) On 23 November 2011 18:58, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
I don't think it's Linux so much as the kinds of things that Alan Kay has observed as being horribly wrong in computer science/engineering education. Â Produce programmers with zero (if not confused/negative) skills in engineering ("no taste" as Steve Jobs said of MS) and you get really bad software.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, November 23, 2011 12:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs
[snip]
P.S. this port collection is crazy.. it still builds dependencies, including python (OMG), and x11 libs.. for a thing, like cairo library.. so much dependencies.. there is something wrong with linux world.
Bill
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
TADAAA: file /opt/local/lib/libcairo.2.dylib /opt/local/lib/libcairo.2.dylib: Mach-O universal binary with 2 architectures /opt/local/lib/libcairo.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /opt/local/lib/libcairo.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 -- Best regards, Igor Stasenko.
Yay! On Wed, Nov 23, 2011 at 07:10:41PM +0100, Igor Stasenko wrote:
TADAAA:
file /opt/local/lib/libcairo.2.dylib /opt/local/lib/libcairo.2.dylib: Mach-O universal binary with 2 architectures /opt/local/lib/libcairo.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /opt/local/lib/libcairo.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
-- Best regards, Igor Stasenko.
Sig, "voodoo dances" is a good characterization. As we were discussing not long ago, it's easy, but definitely NOT simple. Congratulations on getting it working. Thanks for your efforts! Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, November 23, 2011 1:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs nevermind, after multiple painfull upgrade/clean/--enforce-variants and other voodoo dances, i got it installed. Now the question if it will work as expected and can be loaded by 32-bit VM , which is Cog :) On 23 November 2011 18:58, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
I don't think it's Linux so much as the kinds of things that Alan Kay has observed as being horribly wrong in computer science/engineering education. Produce programmers with zero (if not confused/negative) skills in engineering ("no taste" as Steve Jobs said of MS) and you get really bad software.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, November 23, 2011 12:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs
[snip]
P.S. this port collection is crazy.. it still builds dependencies, including python (OMG), and x11 libs.. for a thing, like cairo library.. so much dependencies.. there is something wrong with linux world.
Bill
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Igor since we will want to have that on the build server ;) can you tell a bit what you did that I try on my machine. about portâ¦.. people make me laugh when they say that GTK is available one day it took 8 h to get it installed on my machine and it did not work at all :( Stef On Nov 23, 2011, at 7:05 PM, Igor Stasenko wrote:
nevermind, after multiple painfull upgrade/clean/--enforce-variants and other voodoo dances, i got it installed. Now the question if it will work as expected and can be loaded by 32-bit VM , which is Cog :)
On 23 November 2011 18:58, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
I don't think it's Linux so much as the kinds of things that Alan Kay has observed as being horribly wrong in computer science/engineering education. Produce programmers with zero (if not confused/negative) skills in engineering ("no taste" as Steve Jobs said of MS) and you get really bad software.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua@gmail.com] Sent: Wednesday, November 23, 2011 12:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs
[snip]
P.S. this port collection is crazy.. it still builds dependencies, including python (OMG), and x11 libs.. for a thing, like cairo library.. so much dependencies.. there is something wrong with linux world.
Bill
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 23 November 2011 21:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor
since we will want to have that on the build server ;) can you tell a bit what you did that I try on my machine.
since i installed ports before, and since my system is 64 bit, most of packages are built using 64bit arch. now, since i insisted to also have 32bit libs (obviously to be able to use cairo with VM), i had to reinstall all dependents of cairo (a lot) with +universal flag. so, the basic rule, is whenever you install anything using ports, add +universal option, to make sure that it will produce 'fat' binaries containing both 32bit and 64bit versions. (of course it doubles the compilation time ;)
about portâ¦.. people make me laugh when they say that GTK is available one day it took 8 h to get it installed on my machine and it did not work at all :(
hehe.. to build cairo, for some strange reason it had to rebuild xml, python, perl, x11 lib and dozen of other stuff. rephrasing famous Alan's Kay note: by saying "modularity" i didn't had C dynamic libraries in mind :) now given that cairo library having so much/deep strange dependencies, i am not sure whether we should a) build it on build server b) bundle it with VM a), because port seems to be working, and it is external to our project and maintained by people we do not know. b, because otherwise it may require to bundle VM with 32-bit versions of a lot of libs, which normally can be found in any unix system, and should be installed by user(s) , not us.
Stef
-- Best regards, Igor Stasenko.
On Nov 23, 2011, at 9:45 PM, Igor Stasenko wrote:
On 23 November 2011 21:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor
since we will want to have that on the build server ;) can you tell a bit what you did that I try on my machine.
since i installed ports before, and since my system is 64 bit, most of packages are built using 64bit arch. now, since i insisted to also have 32bit libs (obviously to be able to use cairo with VM), i had to reinstall all dependents of cairo (a lot) with +universal flag.
so, the basic rule, is whenever you install anything using ports, add +universal option, to make sure that it will produce 'fat' binaries containing both 32bit and 64bit versions. (of course it doubles the compilation time ;)
about portâ¦.. people make me laugh when they say that GTK is available one day it took 8 h to get it installed on my machine and it did not work at all :(
hehe.. to build cairo, for some strange reason it had to rebuild xml, python, perl, x11 lib and dozen of other stuff.
rephrasing famous Alan's Kay note: by saying "modularity" i didn't had C dynamic libraries in mind :)
now given that cairo library having so much/deep strange dependencies, i am not sure whether we should a) build it on build server b) bundle it with VM
a), because port seems to be working, and it is external to our project and maintained by people we do not know. b, because otherwise it may require to bundle VM with 32-bit versions of a lot of libs, which normally can be found in any unix system, and should be installed by user(s) , not us.
Indeed we should not :) Now when we will ship pharo it would be good to have a lib included.
Stef
-- Best regards, Igor Stasenko.
I'm going to have to run down that dynamic library quote - I vaguely recall seeing it, but obviously need a refresher course. I *think* I know what he means by it. Though I will admit that when the boundaries are correct, libraries have their uses. All too often though, one ends up with (as here) myriad dependencies that don't seem to have any direct applicability and certainly make life complicated. However, AccesIO (http://www.accesio.com) makes a nice A/D board and they have a library that has been very helpful. The board is perhaps the only USB device, other than external drives, that hasn't been a major pain at some point. Get the firmware and rules installed correctly, and it just works. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, November 23, 2011 4:02 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Building 32-bit Cairo library on Macs On Nov 23, 2011, at 9:45 PM, Igor Stasenko wrote:
On 23 November 2011 21:16, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor
since we will want to have that on the build server ;) can you tell a bit what you did that I try on my machine.
since i installed ports before, and since my system is 64 bit, most of packages are built using 64bit arch. now, since i insisted to also have 32bit libs (obviously to be able to use cairo with VM), i had to reinstall all dependents of cairo (a lot) with +universal flag.
so, the basic rule, is whenever you install anything using ports, add +universal option, to make sure that it will produce 'fat' binaries containing both 32bit and 64bit versions. (of course it doubles the compilation time ;)
about portâ¦.. people make me laugh when they say that GTK is available one day it took 8 h to get it installed on my machine and it did not work at all :(
hehe.. to build cairo, for some strange reason it had to rebuild xml, python, perl, x11 lib and dozen of other stuff.
rephrasing famous Alan's Kay note: by saying "modularity" i didn't had C dynamic libraries in mind :)
now given that cairo library having so much/deep strange dependencies, i am not sure whether we should a) build it on build server b) bundle it with VM
a), because port seems to be working, and it is external to our project and maintained by people we do not know. b, because otherwise it may require to bundle VM with 32-bit versions of a lot of libs, which normally can be found in any unix system, and should be installed by user(s) , not us.
Indeed we should not :) Now when we will ship pharo it would be good to have a lib included.
Stef
-- Best regards, Igor Stasenko.
On 23 November 2011 23:20, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
I'm going to have to run down that dynamic library quote - I vaguely recall seeing it, but obviously need a refresher course.
this is a quote about object-oriented and C++ :) [ Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind. ] -- Best regards, Igor Stasenko.
Just to let you know: it works on Mac! I just loaded the code which Javier did for linux, changed path to library and it worked out of the box. all examples in [1] are working out of the box! So, now i can start wiring Cairo backend for Athens :) [1] http://squeaksource.com/NBCairo/ -- Best regards, Igor Stasenko.
cool We want more :) Stef On Nov 25, 2011, at 5:17 PM, Igor Stasenko wrote:
Just to let you know:
it works on Mac! I just loaded the code which Javier did for linux, changed path to library and it worked out of the box. all examples in [1] are working out of the box!
So, now i can start wiring Cairo backend for Athens :)
[1] http://squeaksource.com/NBCairo/
-- Best regards, Igor Stasenko.
participants (8)
-
David T. Lewis -
Igor Stasenko -
Luc Fabresse -
Schwab,Wilhelm K -
Sean P. DeNigris -
Serge Stinckwich -
Stefan Marr -
Stéphane Ducasse