You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jean-Louis 'Hans' Fuchs <je...@adfinis-sygroup.ch> on 2013/01/07 18:24:57 UTC
GNU Environment (New Build on Solaris)
Hello Everybody
Abstract
-----------
Solaris has differtent system-tools, all the GNU tools are prefixed g-
(ie. gtar). Some tools and dependencies of the build-system have to be
installed from OpenCSW on older solaris. In this mail I discuss how to
integrate these tools in the build-system and a policy to integrate
latest AOO changes (toward GNU) into solaris.
Both topics are too connected to make two mails, but feel free to anwer
only on one topic.
Tools Integration
----------------------
I start a build on a new solaris version. This time I like to ONLY do
mergable changes. The main problem lies in the tools. Many tools (grep,
sed, tar…) are detected in configure. On solaris it will typically
detect (ggrep, gset, gtar…), but most scripts just use the stanard
names anyway.
I don't have a problem with scripts not using the detected tool. I
think we should define GNU-Tools as standard. Otherwise the already
complicated build system gets unnecessary error sources.
I think there are two approaches:
A. Detect all the tools needed in the build system and have every
script use the detected tool.
B. On systems that have prefixes for the GNU tools a pre-step in the
build process creates a GNU Environment. This is how my build system
currently works and it should IMO be integrated into the AOO
build-system-bootstrap.
B "Virtual" GNU Env
(All problems in computer science can be solved by another level of
indirection)
1. If /path/to/build is the build directory, a directory
/path/to/build/bin should be created
2. The directory should be added to PATH="/path/to/build/bin:$PATH"
3. Find the g-prefixed tools and symbol link them into bin without prefix
On a current build system:
oobuild@sunt1000sparc ~/slave/aoo-trunk-solaris-11-sparc/build/bin [8
files, 7.5K] (master)
$> ls -l
total 9
lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 find ->
/opt/csw/bin/gfind
lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 grep ->
/opt/csw/bin/ggrep
lrwxrwxrwx 1 oobuild staff 19 Oct 10 12:34 patch ->
/opt/csw/bin/gpatch
lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 perl ->
/opt/csw/bin/perl *
-rwxr-xr-x 1 oobuild staff 107 Oct 10 12:34 pkg-config *
lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 sed -> /opt/csw/bin/gsed
lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 tar -> /opt/csw/bin/gtar
* Special Cases:
1. On some old solaris I can't easily install all the perl-modules
needed for the build-system. So I installed perl using the thrid-party
package manager OpenCSW.
2. As you see, since I had OpenCSW anyway I used all the OpenCSW tools
to be consistant, many tools would be in standard solaris too.
3. pkg-config:
$> cat pkg-config
#!/bin/bash
export PKG_CONFIG_PATH="/usr/lib/pkgconfig:/usr/share/pkgconfig"
/opt/csw/bin/pkg-config "$@"
pkg-configs command line interaface on solaris 10 was outdated. So I
installed pkg-config in OpenCSW, __BUT__ used a PKG_CONFIG_PATH that it
only finds system libraries, NOT libraries from /opt/csw. I also
checked that our build only depends on system libraries (with the
exception of libpoppler for the pdf plugin)
These fixes must be merged into the build-system, so AOO will build
out-of-the-box. Although I see no way around OpenCSW. But what packages
from OpenCSW are needed could be added to the build-instructions.
Policy
---------
I need to find out what direction we should go, in order to make a
decent proposal.
Can we make OpenCSW manatory? (All our clients had no problem with
that, and it seems pretty standard)
Can we make the "virtual" GNU Env (build/bin) as part of
build-system-bootstrap?
Then some policy definition:
1. I think it is quite possible that we have to link against a library
from OpenCSW in future. Will that be ok?*
* libpoppler is an example. On customer uses the pdf plugin that has
libpoppler from OpenCSW linked.
2. I'd vote for the following policy:
- Use everything possible from Standard Solaris
- Use tools when needed from OpenCSW
- Use these OpenCSW tools through the "virtual" GNU env (no adding of
/opt/csw/bin to path)
- Use libraries from OpenCSW only if there is NO other solution
- Only add library in a per module fashion:
export POPPLER_CFLAGS="-I/opt/csw/include -I/opt/csw/include/poppler"
export POPPLER_LIBS="-L/opt/csw/lib -lpoppler"
- Never generally add /opt/csw/lib
Finally, since I like to switch to GNU-Compiler-Toolchain on solaris
too, building this GNU-Environment will accompany this transition well.
Best,
Jean-Louis
--
Adfinis SyGroup AG
Jean-Louis 'Hans' Fuchs, Software Engineer
Keltenstrasse 98 | CH-3018 Bern
Tel.: +41 31 550 31 11
Re: GNU Environment (New Build on Solaris)
Posted by Pedro Giffuni <pf...@apache.org>.
Hello;
----- Messaggio originale -----
> Da: Jean-Louis 'Hans' Fuchs
> Hello Everybody
>
> Abstract
> -----------
>
> Solaris has differtent system-tools, all the GNU tools are prefixed g- (ie.
> gtar). Some tools and dependencies of the build-system have to be installed from
> OpenCSW on older solaris. In this mail I discuss how to integrate these tools in
> the build-system and a policy to integrate latest AOO changes (toward GNU) into
> solaris.
>
> Both topics are too connected to make two mails, but feel free to anwer only on
> one topic.
>
> Tools Integration
> ----------------------
>
> I start a build on a new solaris version. This time I like to ONLY do mergable
> changes. The main problem lies in the tools. Many tools (grep, sed, tar…) are
> detected in configure. On solaris it will typically detect (ggrep, gset, gtar…),
> but most scripts just use the stanard names anyway.
>
> I don't have a problem with scripts not using the detected tool. I think we
> should define GNU-Tools as standard. Otherwise the already complicated build
> system gets unnecessary error sources.
>
> I think there are two approaches:
>
> A. Detect all the tools needed in the build system and have every script use the
> detected tool.
> B. On systems that have prefixes for the GNU tools a pre-step in the build
> process creates a GNU Environment. This is how my build system currently works
> and it should IMO be integrated into the AOO build-system-bootstrap.
>
Detecting gpatch first than patch would be interesting for FreeBSD too,
however, please don't play too much with configure.in (it's already ugly
in there).
We have some configure options for that:
--with-gnu-patch=
--with-gnu-perf=
We have been able to get rid fo gnucp in FreeBSD too, no idea if that is enough
for Solaris.
> B "Virtual" GNU Env
>
> (All problems in computer science can be solved by another level of indirection)
>
> 1. If /path/to/build is the build directory, a directory /path/to/build/bin
> should be created
> 2. The directory should be added to PATH="/path/to/build/bin:$PATH"
> 3. Find the g-prefixed tools and symbol link them into bin without prefix
>
> On a current build system:
> oobuild@sunt1000sparc ~/slave/aoo-trunk-solaris-11-sparc/build/bin [8 files,
> 7.5K] (master)
> $> ls -l
> total 9
> lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 find ->
> /opt/csw/bin/gfind
> lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 grep ->
> /opt/csw/bin/ggrep
> lrwxrwxrwx 1 oobuild staff 19 Oct 10 12:34 patch ->
> /opt/csw/bin/gpatch
> lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 perl ->
> /opt/csw/bin/perl *
> -rwxr-xr-x 1 oobuild staff 107 Oct 10 12:34 pkg-config *
> lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 sed ->
> /opt/csw/bin/gsed
> lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 tar ->
> /opt/csw/bin/gtar
>
n general avoiding the use of GNU tools with more generic utilities is ideal.
In FreeBSD we were able to get rid of GNU coreutils (gcp and GNU mktemp
I think). BSD tar and BSD sed (included in illumos) work fine for us.
> * Special Cases:
>
> 1. On some old solaris I can't easily install all the perl-modules needed
> for the build-system. So I installed perl using the thrid-party package manager
> OpenCSW.
> 2. As you see, since I had OpenCSW anyway I used all the OpenCSW tools to be
> consistant, many tools would be in standard solaris too.
> 3. pkg-config:
>
> $> cat pkg-config
> #!/bin/bash
>
Please note that this shebang would be totally unacceptable for AOO.
http://lwn.net/Articles/343924/
If you *have* to use bash try #/usr/bin/env bash
>
> Policy
> ---------
>
> I need to find out what direction we should go, in order to make a decent
> proposal.
>
> Can we make OpenCSW manatory? (All our clients had no problem with that, and it
> seems pretty standard)
Not a problem. A matter of documentation, I guess.
> Can we make the "virtual" GNU Env (build/bin) as part of
> build-system-bootstrap?
>
> Then some policy definition:
>
> 1. I think it is quite possible that we have to link against a library from
> OpenCSW in future. Will that be ok?*
>
> * libpoppler is an example. On customer uses the pdf plugin that has libpoppler
> from OpenCSW linked.
>
> 2. I'd vote for the following policy:
>
> - Use everything possible from Standard Solaris
> - Use tools when needed from OpenCSW
> - Use these OpenCSW tools through the "virtual" GNU env (no adding of
> /opt/csw/bin to path)
> - Use libraries from OpenCSW only if there is NO other solution
> - Only add library in a per module fashion:
>
> export POPPLER_CFLAGS="-I/opt/csw/include -I/opt/csw/include/poppler"
> export POPPLER_LIBS="-L/opt/csw/lib -lpoppler"
>
> - Never generally add /opt/csw/lib
>
In general there is a lot of flexibility. It is ideal to use configure properly
to avoid doing work manually but as long as you don't interfere negatively
with other platforms it is OK.
> Finally, since I like to switch to GNU-Compiler-Toolchain on solaris too,
> building this GNU-Environment will accompany this transition well.
>
That will be the interesting part.
Pedro.
Re: GNU Environment (New Build on Solaris)
Posted by janI <ja...@apache.org>.
On 7 January 2013 18:24, Jean-Louis 'Hans' Fuchs <
jean-louis.fuchs@adfinis-sygroup.ch> wrote:
> Hello Everybody
>
> Abstract
> -----------
>
> Solaris has differtent system-tools, all the GNU tools are prefixed g-
> (ie. gtar). Some tools and dependencies of the build-system have to be
> installed from OpenCSW on older solaris. In this mail I discuss how to
> integrate these tools in the build-system and a policy to integrate latest
> AOO changes (toward GNU) into solaris.
>
> Both topics are too connected to make two mails, but feel free to anwer
> only on one topic.
>
> Tools Integration
> ----------------------
>
> I start a build on a new solaris version. This time I like to ONLY do
> mergable changes. The main problem lies in the tools. Many tools (grep,
> sed, tar…) are detected in configure. On solaris it will typically detect
> (ggrep, gset, gtar…), but most scripts just use the stanard names anyway.
>
> I don't have a problem with scripts not using the detected tool. I think
> we should define GNU-Tools as standard. Otherwise the already complicated
> build system gets unnecessary error sources.
>
> I think there are two approaches:
>
> A. Detect all the tools needed in the build system and have every script
> use the detected tool.
> B. On systems that have prefixes for the GNU tools a pre-step in the build
> process creates a GNU Environment. This is how my build system currently
> works and it should IMO be integrated into the AOO build-system-bootstrap.
>
> B "Virtual" GNU Env
>
> (All problems in computer science can be solved by another level of
> indirection)
>
> 1. If /path/to/build is the build directory, a directory
> /path/to/build/bin should be created
> 2. The directory should be added to PATH="/path/to/build/bin:$**PATH"
> 3. Find the g-prefixed tools and symbol link them into bin without prefix
>
> On a current build system:
> oobuild@sunt1000sparc ~/slave/aoo-trunk-solaris-11-**sparc/build/bin [8
> files, 7.5K] (master)
> $> ls -l
> total 9
> lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 find ->
> /opt/csw/bin/gfind
> lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 grep ->
> /opt/csw/bin/ggrep
> lrwxrwxrwx 1 oobuild staff 19 Oct 10 12:34 patch ->
> /opt/csw/bin/gpatch
> lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 perl ->
> /opt/csw/bin/perl *
> -rwxr-xr-x 1 oobuild staff 107 Oct 10 12:34 pkg-config *
> lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 sed ->
> /opt/csw/bin/gsed
> lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 tar ->
> /opt/csw/bin/gtar
>
> * Special Cases:
>
> 1. On some old solaris I can't easily install all the perl-modules needed
> for the build-system. So I installed perl using the thrid-party package
> manager OpenCSW.
> 2. As you see, since I had OpenCSW anyway I used all the OpenCSW tools to
> be consistant, many tools would be in standard solaris too.
> 3. pkg-config:
>
> $> cat pkg-config
> #!/bin/bash
>
> export PKG_CONFIG_PATH="/usr/lib/**pkgconfig:/usr/share/**pkgconfig"
> /opt/csw/bin/pkg-config "$@"
>
> pkg-configs command line interaface on solaris 10 was outdated. So I
> installed pkg-config in OpenCSW, __BUT__ used a PKG_CONFIG_PATH that it
> only finds system libraries, NOT libraries from /opt/csw. I also checked
> that our build only depends on system libraries (with the exception of
> libpoppler for the pdf plugin)
>
> These fixes must be merged into the build-system, so AOO will build
> out-of-the-box. Although I see no way around OpenCSW. But what packages
> from OpenCSW are needed could be added to the build-instructions.
>
> Policy
> ---------
>
> I need to find out what direction we should go, in order to make a decent
> proposal.
>
> Can we make OpenCSW manatory? (All our clients had no problem with that,
> and it seems pretty standard)
> Can we make the "virtual" GNU Env (build/bin) as part of
> build-system-bootstrap?
>
> Then some policy definition:
>
> 1. I think it is quite possible that we have to link against a library
> from OpenCSW in future. Will that be ok?*
>
> * libpoppler is an example. On customer uses the pdf plugin that has
> libpoppler from OpenCSW linked.
>
> 2. I'd vote for the following policy:
>
> - Use everything possible from Standard Solaris
> - Use tools when needed from OpenCSW
> - Use these OpenCSW tools through the "virtual" GNU env (no adding of
> /opt/csw/bin to path)
> - Use libraries from OpenCSW only if there is NO other solution
> - Only add library in a per module fashion:
>
> export POPPLER_CFLAGS="-I/opt/csw/**include -I/opt/csw/include/poppler"
> export POPPLER_LIBS="-L/opt/csw/lib -lpoppler"
>
> - Never generally add /opt/csw/lib
>
> Finally, since I like to switch to GNU-Compiler-Toolchain on solaris too,
> building this GNU-Environment will accompany this transition well.
>
Your proposal also has the advantage that when we move on with gbuild and
other changes in the build structure, it is easy to adapt to solaris.
The libraries is somewhat a different matter. Today bootstrap secures we
have the external libraries needed, I would prefer to keep that, and not
start having too many extra things that need to be installed manually. We
also have to check the license of such libraries, many libraries are free
to use for individuals but not for organisations, depending upon such a
library would be a problem in my view.
As a side remark, I worked prof. with solaris about 5 years ago, and at
that time there was a BIG performance penalty when using gcc/g++ in large
projects compared to the sun compiler. That might have changed, but I
recommend strongly to test it.
Rgds
jan I.
>
> Best,
> Jean-Louis
>
> --
> Adfinis SyGroup AG
> Jean-Louis 'Hans' Fuchs, Software Engineer
>
> Keltenstrasse 98 | CH-3018 Bern
> Tel.: +41 31 550 31 11
>
>
>