Re: [OpenIndiana-discuss] Building applications
Hello. russell писал 04.06.2015 22:27: Hi, After getting frustrated with running Firefox 31.3.0 crashing on OpenIndiana if it was left running for any length of time. I did start the process of building Firefox v38.0.1. As a result of this I found a couple of things when attempting to do this, the pulseaudio library was not installed an easy fix if you know its there. The question should be "Should PulseAudio be installed by default on a desktop install?". I would say yes. It should be installed by default after recent Hipster updates. Carrying on with Firefox, I had to work to find a reasonable configure command, this was after working out the best value for PATH so that the right version of the GNU applications are called for configure to work correctly. CC=gcc PKG_CONFIG_PATH="/opt/gnu/lib/pkgconfig" CPPFLAGS=-I/opt/gnu/include LDFLAGS="-L/opt/gnu/lib -R/opt/gnu/lib -lsocket -lnsl" ../mozilla-release/configure --prefix=/opt/firefox-38.0.1 --disable-alsa Now I got the stage that configure reports the following error. configure: error: ECMAScript Internationalization API is not yet supported on this platform You can take a look at my FF 31 version (mostly based on pkgsrc one). Unfortunately, this version doesn't work with flash plugin... --- System Administrator of Southern Federal University Computer Center ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Building applications
Hi, After getting frustrated with running Firefox 31.3.0 crashing on OpenIndiana if it was left running for any length of time. I did start the process of building Firefox v38.0.1. As a result of this I found a couple of things when attempting to do this, the pulseaudio library was not installed an easy fix if you know its there. The question should be "Should PulseAudio be installed by default on a desktop install?". I would say yes. Carrying on with Firefox, I had to work to find a reasonable configure command, this was after working out the best value for PATH so that the right version of the GNU applications are called for configure to work correctly. CC=gcc PKG_CONFIG_PATH="/opt/gnu/lib/pkgconfig" CPPFLAGS=-I/opt/gnu/include LDFLAGS="-L/opt/gnu/lib -R/opt/gnu/lib -lsocket -lnsl" ../mozilla-release/configure --prefix=/opt/firefox-38.0.1 --disable-alsa Now I got the stage that configure reports the following error. configure: error: ECMAScript Internationalization API is not yet supported on this platform Google is our friend and this presents the following as an option https://groups.google.com/forum/#!topic/nodejs/s0XMutjEAR which basically informs us that the node.js from nodejs.org provides ECMAScript Internationalization API 1.0 support. The current release of node.js is v0.12.4 which is available as solaris x86 and x64 binaries. I tried to build the latest myself and hit a dependency. Since going through the process of building all VLC's dependencies and then failing to build VLC itself was very annoying. However VLC failed because of strerror_l() function expected in the string.h include file. It is the dependencies that are problem when building applications because many dependency libraries are not there and have to built first. Surely anyone wanting to build Firefox should find it a simple matter of downloading the source code, unpacking, running configure and then gmake. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
On 10/19/10 04:43 AM, Alan Coopersmith wrote: Albert Lee wrote: pkg(5) has a as-yet unused "facet" mechanism that would let you filter components of packages to not be installed; for example, development files or documentation. While it's not yet widely used, X has bravely stepped forward as a test case - you should be able to disable the doc or devel facets and see the man pages, headers, etc. from the X consolidation disappear. Most of the magic in the X build to mark files with their facets is in: http://src.opensolaris.org/source/xref/x-cons/xnv-clone/pkg/transforms/facets though some packages have them directly in the package manifest as well for files that don't match the common patterns. More consolidations should be tagging their packages with facets in the future. facets are a very nice pkg(5) feature, however on bad side isn't a case of all or nothing ? or I understood it wrong ? e.g, is possible to install package x without doc files, but only package x, leaving system image untouched ?. Regargs, Carlos Almeida, ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
Albert Lee wrote: > pkg(5) has a as-yet > unused "facet" mechanism that would let you filter components of > packages to not be installed; for example, development files or > documentation. While it's not yet widely used, X has bravely stepped forward as a test case - you should be able to disable the doc or devel facets and see the man pages, headers, etc. from the X consolidation disappear. Most of the magic in the X build to mark files with their facets is in: http://src.opensolaris.org/source/xref/x-cons/xnv-clone/pkg/transforms/facets though some packages have them directly in the package manifest as well for files that don't match the common patterns. More consolidations should be tagging their packages with facets in the future. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
On Fri, Oct 15, 2010 at 4:45 AM, Albert Lee wrote: > Solaris on SPARC, which has had no 32-bit systems for even longer (and > no 64-bit kernel since S10), ^ Typo, that line was supposed to be "no 32-bit kernel", of course. -Albert ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
And please make sure that 32-bit apps get built largefile-aware. There are enough of them that aren't, that it's a nuisance sometimes. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
On Fri, Oct 15, 2010 at 3:35 AM, russell wrote: > Hi Alasdair, > > From a personal perspective I would prefer if everything was 64bit and 32bit > libraries were provided for backward compatibility. I see no reason to > provide 32bit binaries if 64bit versions can be created, 64bit x86 chips > have been available since 2003, virtually all the CPUs on the market are > 64bit capable. The only reason to support 32bit binaries are for older > computers with older cpus, or the application is not 64bit aware. ZFS > provides us with a 128bit filesystem but we cling on to antiquated 32bit > applications. > Solaris on SPARC, which has had no 32-bit systems for even longer (and no 64-bit kernel since S10), still includes 32-bit applications because 64-bit versions are often slower. This happens less frequently on x86 because IA-32 performance can be impaired, but it's still an important reason. The number of bits ZFS uses in its storage addressing scheme is largely irrelevant. Perhaps a decade or so down the road, we can stop building 32-bit applications. > However, some people may feel that that is bit draconian, so may I suggest a > more acceptable alternative. > Provide within Package Manager, a 64/32 bit application preference option > (which the user selects and the system records), the list of Packages > provided are then dependant of the users 64/32bit choice. If an application > is available as a combined 64 and 32 bit application then it is always > listed irrespective of the users choice. > All regular applications have a plain 32-bit version. An application can support multiple extended ISAs using a standard mechanism (see isalist(5), isaexec(3)), allowing the instruction set to be selected at runtime. These are usually delivered as a combined package. The 64-bit ISA is handled the same way as the others. pkg(5) has a as-yet unused "facet" mechanism that would let you filter components of packages to not be installed; for example, development files or documentation. Adding arch tags has been proposed, although I think the original use case was for not wasting space on 32-bit systems. > Unfortunately this will result in many applications having to be built in 32 > and 64 bit versions. The IPS servers will record the number of downloads 32 > v 64 bit and the results can be published annually. All standard "64-bit" applications are already combined 32- and 64-bit. -Albert ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
Hi Alasdair, From a personal perspective I would prefer if everything was 64bit and 32bit libraries were provided for backward compatibility. I see no reason to provide 32bit binaries if 64bit versions can be created, 64bit x86 chips have been available since 2003, virtually all the CPUs on the market are 64bit capable. The only reason to support 32bit binaries are for older computers with older cpus, or the application is not 64bit aware. ZFS provides us with a 128bit filesystem but we cling on to antiquated 32bit applications. However, some people may feel that that is bit draconian, so may I suggest a more acceptable alternative. Provide within Package Manager, a 64/32 bit application preference option (which the user selects and the system records), the list of Packages provided are then dependant of the users 64/32bit choice. If an application is available as a combined 64 and 32 bit application then it is always listed irrespective of the users choice. Unfortunately this will result in many applications having to be built in 32 and 64 bit versions. The IPS servers will record the number of downloads 32 v 64 bit and the results can be published annually. Hopefully we can find a solution acceptable to all Regards Russell ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
On Thursday, 14 October, 2010 17:09, "Alasdair Lumsden" said: > So perhaps not too impossible, and hopefully not too icky. Just need someone > who > has the time to implement it, either by modifying/extending the SFW Perl 5.10 > build, or to replace that with a JDS style specfile. Ah, a mixed 32/64-bit *package*. That's not icky, and that makes sense. I meant that a mixed 32/64-bit executable and trying to mix 32/64-bit extensions would be ugly. Just ignore me. :) Cheers, kjw ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
On 14 Oct 2010, at 22:31, Kevin J. Woolley wrote: > I don't believe a combined 32/64-bit Perl is possible. If it was, it'd still > be pretty icky, from an implementation point of view. (Is it possible for a > 64-bit binary to dynamically load 32-bit libs? I'm pretty sure the reverse > isn't possible.) There was a bit of talk on #oi-dev about this this evening and some thoughts were: 1. It'd be nice to yank perl 5.8.4 from ONNV (but for the time being, still require perl 5.10 to be installed to build/use the OS, but use the one from SFW) 2. Perhaps at some point in the future remove the dependency on Perl for the OS to run (would require rewriting things) 3. Add 64bit support to the perl 5.10 SFW package so it becomes a combined 32bit/64bit package, similar to the Python package. Basically the combined 32bit/64bit package would follow the usual ISA conventions of eg. /usr/bin/perl, /usr/bin/amd64/perl, with separate 32bit and 64bit extension directories. That way if you run a 32bit perl, it uses 32bit extensions, and for 64bit perl it uses 64bit extensions. Obviously if you use 32bit CPAN to install modules they'll only appear in the 32bit extensions dir (and vice versa for 64bit), which might be confusing for some people, but at least it would provide the 64bit option. So perhaps not too impossible, and hopefully not too icky. Just need someone who has the time to implement it, either by modifying/extending the SFW Perl 5.10 build, or to replace that with a JDS style specfile. Cheers, Alasdair ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
Alasdair, I'd lobby for the separate directory approach. We were running into this in openSolaris, when trying to build PostgreSQL. Our issues were related to multiple versions of perl, granted, not multiple architectures. There was a bit of back-and-forth as to whether it was an 'OS layout' issue or a 'configuration' script issue (my words); we may have an opportunity to blaze a little bit of trail here. Thanks again for the hard work, Lou Picciano - Original Message - From: "Alasdair Lumsden" To: "Discussion list for OpenIndiana" Sent: Thursday, October 14, 2010 5:19:30 PM Subject: Re: [OpenIndiana-discuss] Building Applications On 13 Oct 2010, at 15:36, russell wrote: > Hi, > > While OpenIndiana (OpenSolaris/Solaris) provide 32 and 64 bit libraries for > building 64 bit applications. > However if you want to include bindings to Perl for example, the version > shipped with OpenIndiana is 32bit including it libraries. So, if you want to > include Perl support in a 64bit application, you need to build a 64bit > version of Perl before building your 64bit application. > Is there a way of including 64bit version of standard applications like Perl > within OpenIndiana, so that building a 64bit version of PostgreSQL can > utilise a standard 64 bit version of Perl, maybe in a /usr/bin64 directory? Hi Russell, That looks like an oversight in the OS worth addressing. I imagine getting a combined 32/64bit perl on the system would be very difficult, given perl modules install native extensions. Essentially you'd need separate extension directories and at that point you may as well have two separate perl prefixes. Perhaps an optional installable /usr/perl5-64 ? I'd be interested to hear what suggestions people have, as none of the options I can think of are terribly neat and tidy. Cheers, Alasdair ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
On Thursday, 14 October, 2010 14:19, "Alasdair Lumsden" said: > Hi Russell, > > That looks like an oversight in the OS worth addressing. > > I imagine getting a combined 32/64bit perl on the system would be very > difficult, > given perl modules install native extensions. Essentially you'd need separate > extension directories and at that point you may as well have two separate perl > prefixes. Perhaps an optional installable /usr/perl5-64 ? > > I'd be interested to hear what suggestions people have, as none of the > options I > can think of are terribly neat and tidy. I don't believe a combined 32/64-bit Perl is possible. If it was, it'd still be pretty icky, from an implementation point of view. (Is it possible for a 64-bit binary to dynamically load 32-bit libs? I'm pretty sure the reverse isn't possible.) Two separate prefixes isn't a bad thing, and it's what I used in my testing set-ups when I tested Perl releases for $dayjob. I'd have /opt/perl32 and /opt/perl64 (for example), then either change my path to pick up just one of them or symlink one perl executable into /opt/bin and run it from there. It's easy enough to change manually once you've done a "file /usr/bin/perl" to figure out what's going on, and even easier to add a switch-to-perl64.sh or whatever to redo the symlinks if someone wants to change the default Perl. Cheers, kjw ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Building Applications
On 13 Oct 2010, at 15:36, russell wrote: > Hi, > > While OpenIndiana (OpenSolaris/Solaris) provide 32 and 64 bit libraries for > building 64 bit applications. > However if you want to include bindings to Perl for example, the version > shipped with OpenIndiana is 32bit including it libraries. So, if you want to > include Perl support in a 64bit application, you need to build a 64bit > version of Perl before building your 64bit application. > Is there a way of including 64bit version of standard applications like Perl > within OpenIndiana, so that building a 64bit version of PostgreSQL can > utilise a standard 64 bit version of Perl, maybe in a /usr/bin64 directory? Hi Russell, That looks like an oversight in the OS worth addressing. I imagine getting a combined 32/64bit perl on the system would be very difficult, given perl modules install native extensions. Essentially you'd need separate extension directories and at that point you may as well have two separate perl prefixes. Perhaps an optional installable /usr/perl5-64 ? I'd be interested to hear what suggestions people have, as none of the options I can think of are terribly neat and tidy. Cheers, Alasdair ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Building Applications
Hi, While OpenIndiana (OpenSolaris/Solaris) provide 32 and 64 bit libraries for building 64 bit applications. However if you want to include bindings to Perl for example, the version shipped with OpenIndiana is 32bit including it libraries. So, if you want to include Perl support in a 64bit application, you need to build a 64bit version of Perl before building your 64bit application. Is there a way of including 64bit version of standard applications like Perl within OpenIndiana, so that building a 64bit version of PostgreSQL can utilise a standard 64 bit version of Perl, maybe in a /usr/bin64 directory? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
