[CURRENT]: can't build subversion on Solaris 10
I am unable to build subversion 1.4.0 on my Solaris 10 machine with OpenPKG-CURRENT. It appears that on Solaris 10, one needs to link with -lrt in order to use Berkeley DB, or at least portions thereof. See the attached section of config.log from the apr-util directory: [...] configure:18966: $? = 0 configure:18986: result: yes configure:19021: checking for db.h configure:19028: result: yes configure:19044: checking for -ldb configure:19110: /openpkg-current/bin/cc -o conftest -O2 -pipe -I/openpkg-current/in clude/libxml2 -I/openpkg-current/include -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/openpkg-current/include -L/openpkg-current/lib -L/openpkg-current/lib conftest.c -ldb 5 conftest.c: In function 'main': conftest.c:32: warning: incompatible implicit declaration of built-in function 'exit ' /openpkg-current/lib/libdb.a(os_fsync.o): In function `__os_fsync': os_fsync.c:(.text+0x85): undefined reference to `fdatasync' collect2: ld returned 1 exit status configure:19113: $? = 1 configure: program exited with status 1 [...] According to the Solaris man pages, fdatasync requires linking with -lrt. -- Caleb Epstein __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Build Crashing on AIX 5.2
AIX 5.2 w/ML9. I've tried to build OpenPKG-stable with gcc 4.0.0 (IBM rpm) and 4.0.1 (UCLA binary) and both crash during the building of perl: Which of these apply, if any? [aix] Operating system name? [aix] Operating system version? [5.2.0.0] Build Perl for SOCKS? [n] Use the PerlIO abstraction layer? [y] Build a threading Perl? [n] Build Perl for multiplicity? [n] Use which C compiler? [/usr/bin/gcc] Checking for GNU cc in disguise and/or its version number... At this point the system coredumps and reboots. __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Build Crashing on AIX 5.2
On Mon, Sep 18, 2006, Doug Summers wrote: AIX 5.2 w/ML9. I've tried to build OpenPKG-stable with gcc 4.0.0 (IBM rpm) and 4.0.1 (UCLA binary) and both crash during the building of perl: Which of these apply, if any? [aix] Operating system name? [aix] Operating system version? [5.2.0.0] Build Perl for SOCKS? [n] Use the PerlIO abstraction layer? [y] Build a threading Perl? [n] Build Perl for multiplicity? [n] Use which C compiler? [/usr/bin/gcc] Checking for GNU cc in disguise and/or its version number... At this point the system coredumps and reboots. Well, sorry, that's too less information for anybody to be able to have any clue what the root of the problem is and how to solve or workaround it. You have to dig a little bit deeper yourself here, Doug. The OpenPKG Foundation has no AIX box available on which we could reproduce the problem ourself... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: [CURRENT]: can't build subversion on Solaris 10
On Mon, Sep 18, 2006, Caleb Epstein wrote: I am unable to build subversion 1.4.0 on my Solaris 10 machine with OpenPKG-CURRENT. It appears that on Solaris 10, one needs to link with -lrt in order to use Berkeley DB, or at least portions thereof. See the attached section of config.log from the apr-util directory: [...] configure:18966: $? = 0 configure:18986: result: yes configure:19021: checking for db.h configure:19028: result: yes configure:19044: checking for -ldb configure:19110: /openpkg-current/bin/cc -o conftest -O2 -pipe -I/openpkg-current/in clude/libxml2 -I/openpkg-current/include -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/openpkg-current/include -L/openpkg-current/lib -L/openpkg-current/lib conftest.c -ldb 5 conftest.c: In function 'main': conftest.c:32: warning: incompatible implicit declaration of built-in function 'exit ' /openpkg-current/lib/libdb.a(os_fsync.o): In function `__os_fsync': os_fsync.c:(.text+0x85): undefined reference to `fdatasync' collect2: ld returned 1 exit status configure:19113: $? = 1 configure: program exited with status 1 [...] According to the Solaris man pages, fdatasync requires linking with -lrt. Ok, now fixed: http://cvs.openpkg.org/chngview?cn=30112 Thanks for reporting this problem. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: Build Crashing on AIX 5.2
On Mon, Sep 18, 2006, Doug Summers wrote: Ralf S. Engelschall wrote: On Mon, Sep 18, 2006, Doug Summers wrote: AIX 5.2 w/ML9. I've tried to build OpenPKG-stable with gcc 4.0.0 (IBM rpm) and 4.0.1 (UCLA binary) and both crash during the building of perl: Which of these apply, if any? [aix] Operating system name? [aix] Operating system version? [5.2.0.0] Build Perl for SOCKS? [n] Use the PerlIO abstraction layer? [y] Build a threading Perl? [n] Build Perl for multiplicity? [n] Use which C compiler? [/usr/bin/gcc] Checking for GNU cc in disguise and/or its version number... At this point the system coredumps and reboots. Well, sorry, that's too less information for anybody to be able to have any clue what the root of the problem is and how to solve or workaround it. You have to dig a little bit deeper yourself here, Doug. The OpenPKG Foundation has no AIX box available on which we could reproduce the problem ourself... Sorry about that, Ralph. I realized how vague this message was right after I sent it. I'm trying another build now - what files should I be looking for? Well, in this case I think you have to look inside the Configure script of Perl, there for code around the string Checking for GNU cc in disguise and/or its version number and try this code manually on the command-line to make sure that it still fails. If it's a piece of C code, compile it with gcc -g (debug symbols enabled) and run it with gdb and once it segfaults run bt. The output of the bt command usually gives us at least a hint where the problem migth be. It could be also that the vendor GCC has some optimizer problems. In this case try to compile the piece of C code with and without -O0. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
Re: perl-dbix 2.20060622 asks for input?
On Mon, Sep 18, 2006 at 02:56:34PM -0700, Adam D. Morley wrote:
On Mon, Sep 18, 2006 at 09:47:12PM +0200, Ralf S. Engelschall wrote:
On Mon, Sep 18, 2006, Adam D. Morley wrote:
I'm upgrading a 2.5 OpenPKG instance on Solaris 10 to 2.20060622.
Everything has gone fine so far, but when openpkg build tries to build
perl-dbix, it starts asking for input. First, it can't find the
MIRRORED.BY file, since it isn't detecting http_proxy from the
environment (see MIRRORED.BY.log). I'm guessing this is the same bug as
the RPM 4.4 bug?
If I manually download MIRRORED.BY to /opt/openpkg/.cpan/sources, I get
asked (in a loop) for where I am in the world (see locale.loop.log) by
CPAN's Config.pm.
Other perl packages have been built fine, so I'm wondering if I'm doing
something wrong, or if perl-dbix is the only one that uses CPAN. It
seems odd to use CPAN, but I don't know much about perl-dbix's source
rpm. Can building perl-dbix be made to not require user
input/configuration of CPAN? Or do I just need to configure CPAN
manually? If so, how do I get OpenPKG to tell me all the values it was
going to manually program CPAN with?
Thanks,
--
adam
/var/tmp/opkg/SRC/perl-dbix-5.8.8-2.20060622.src.rpm
Installing /var/tmp/opkg/SRC/perl-dbix-5.8.8-2.20060622.src.rpm
Executing(%prep): env -i /opt/openpkg/lib/openpkg/bash --norc --noprofile
--posix -e /opt/openpkg/RPM/TMP/rpm-tmp.12743
[...]
[Core Features]
- Test::More ...loaded. (0.62 = 0.52)
- DBD::SQLite...missing.
- DBI...loaded. (1.51)
- Want ...loaded. (0.10)
- Encode ...loaded. (2.18)
- Class::ReturnValue ...loaded. (0.53 = 0.4)
- Cache::MemoryCache ...loaded. (0)
- Clone ...loaded. (0.20)
== Auto-install the 1 mandatory module(s) from CPAN? [Y/n] y
[Lower case API]
[...]
OpenPKG packages never should download anything their own. The issue is
That's kind of what I expected, which is why I was surprised.
not related to RPM. It is just that the CPAN stuff detected that for
whatever obscure reasons DBD::SQLite is missing here. The perl-dbix
package depends on the perl-dbi package which in turn provides
DBD::SQLite by default. Please check your perl-dbi package. Either
it has build-option with_dbd_sqlite set to no (which is _NOT_ the
default) or something failed during building of DBD::SQLite in this
package. Just rebuild perl-dbi again and watch for errors.
[this is slightly rambly, as I was trying to figure out what's going on]
It does indeed have with_dbd_sqlite set to no. Here's the tail end of
the output of openpkg build -z -r /var/tmp/opkg perl-dbi
(/var/tmp/opkg is a local cache of ftp.openpkg.org, circa last Thursday
or so, since we're behind a proxy. without -r, the results are the
same):
echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm
/opt/openpkg/bin/openpkg rpm --define 'with_dbd_sqlite no' --rebuild
/var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm || exit $?
/opt/openpkg/bin/openpkg rpm --force -Uvh
/opt/openpkg/RPM/PKG/perl-dbi-5.8.8-2.20060622.sparc64-solaris10-oop.rpm
|| exit $?
echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm = $?
The problem is: I built the package normally with 2.5. Further,
another system running the exact same version of OpenPKG that I'm
upgrading from reports the following from openpkg build -z perl-dbi:
echo
ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm
/opt/openpkg/bin/openpkg rpm --rebuild
ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm ||
exit $?
/opt/openpkg/bin/openpkg rpm --force -Uvh
/opt/openpkg/RPM/PKG/perl-dbi-5.8.7-2.5.0.sparc64-solaris10-oop.rpm ||
exit $?
echo
ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm = $?
So somewhere, the option got twiddled. I do know that the src rpm I
downloaded for 2.20060622 has the option set correctly at yes. But,
upon trying to manually build the package from the source rpm, I get:
[root perl-dbi]# openpkg rpm -bb perl-dbi.spec
error: Failed build dependencies:
sqlite is needed by perl-dbi-5.8.8-2.20060622
So somewhere from the upgrade to 2.5 to 2.20060622, openpkg build seems
to have missed the addition of sqlite as a requirement for perl-dbi.
Likely because 2.5's perl-dbi has with_dbd_sqlite set to no, so the
build script must not consider this possibility? I take it the best way
to reset the option is to manually build sqlite, then rebuild perl-dbi
manually, and then continue with the -ZaKB?
Ah. Even after I manually built gawk, sqlite, and perl-dbi, perl-dbix still
fails:
[Core Features]
- Test::More ...loaded. (0.62 = 0.52)
- DBD::SQLite...missing.
- DBI...loaded. (1.51)
- Want ...loaded. (0.10)
- Encode
Re: perl-dbix 2.20060622 asks for input?
On Mon, Sep 18, 2006 at 04:51:24PM -0700, Adam D. Morley wrote: On Mon, Sep 18, 2006 at 02:56:34PM -0700, Adam D. Morley wrote: So somewhere from the upgrade to 2.5 to 2.20060622, openpkg build seems to have missed the addition of sqlite as a requirement for perl-dbi. Likely because 2.5's perl-dbi has with_dbd_sqlite set to no, so the build script must not consider this possibility? I take it the best way to reset the option is to manually build sqlite, then rebuild perl-dbi manually, and then continue with the -ZaKB? Ah. Even after I manually built gawk, sqlite, and perl-dbi, perl-dbix still fails: [Core Features] - Test::More ...loaded. (0.62 = 0.52) - DBD::SQLite...missing. - DBI...loaded. (1.51) - Want ...loaded. (0.10) - Encode ...loaded. (2.18) - Class::ReturnValue ...loaded. (0.53 = 0.4) - Cache::MemoryCache ...loaded. (0) - Clone ...loaded. (0.20) == Auto-install the 1 mandatory module(s) from CPAN? [Y/n] y [Lower case API] - capitalization ...missing. (would need 0.03) == Auto-install the 1 optional module(s) from CPAN? [y/N] n [Schema generation] - DBIx::DBSchema ...loaded. (0.31) - Class::Accessor...loaded. (0.25) But it seems perl-dbi built SQLLite fine? (see attached) And openpkg This time, with attachment. build -z perl-dbi shows (after I rm the binary rpm): ... echo ftp://ftp.openpkg.org/stable/2.20060622/SRC/perl-dbi-5.8.8-2.20060622.src.rpm /opt/openpkg/bin/openpkg rpm --rebuild ftp://ftp.openpkg.org/stable/2.20060622/SRC/perl-dbi-5.8.8-2.20060622.src.rpm || exit $? /opt/openpkg/bin/openpkg rpm --force -Uvh /opt/openpkg/RPM/PKG/perl-dbi-5.8.8-2.20060622.sparc64-solaris10-oop.rpm || exit $? echo ftp://ftp.openpkg.org/stable/2.20060622/SRC/perl-dbi-5.8.8-2.20060622.src.rpm = $? I'm clearly doing something wrong here. Any ideas? -- adam __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org -- adam ... + /opt/openpkg/bin/perl-openpkg configure build install ++ OpenPKG perl-openpkg 2.0.1 (03-Dec-2004) ++ determined RPM program: /opt/openpkg/libexec/openpkg/rpm (4.2.1) ++ determined Perl program: /opt/openpkg/bin/perl (5.8.8) ++ step 2: configure ++ configuring module via ExtUtils::MakeMaker environment Checking installed SQLite version... SQLite version must be at least 3.1.3. No header file at that version or higher was found. Using the local version instead. Checking if your kit is complete... Looks good Multiple copies of Driver.xst found in: /opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/ /opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/ at ./Makefile.PL line 106 Using DBI 1.51 (for perl 5.008008 on sun4-solaris) installed in /opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/ Writing Makefile for DBD::SQLite ++ step 3: build ++ building module via ExtUtils::MakeMaker environment cp lib/DBD/SQLite.pm blib/lib/DBD/SQLite.pm /opt/openpkg/RPM/TMP/adam-perl-openpkg-perl-dbi/perl.sh -p -e s/~DRIVER~/SQLite/g /opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI/Driver.xst SQLite.xsi /opt/openpkg/RPM/TMP/adam-perl-openpkg-perl-dbi/perl.sh /opt/openpkg/lib/perl/5.8.8/ExtUtils/xsubpp -typemap /opt/openpkg/lib/perl/5.8.8/ExtUtils/typemap SQLite.xs SQLite.xsc mv SQLite.xsc SQLite.c /opt/openpkg/bin/cc -c -I/opt/openpkg/include -I/opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/openpkg/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -O2 -DVERSION=\1.12\ -DXS_VERSION=\1.12\ -fPIC -I/opt/openpkg/lib/perl/5.8.8/sun4-solaris/CORE -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 SQLite.c /opt/openpkg/bin/cc -c -I/opt/openpkg/include -I/opt/openpkg/RPM/TMP/perl-dbi-5.8.8-root/opt/openpkg/lib/perl/vendor_perl/5.8.8/sun4-solaris/auto/DBI -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/opt/openpkg/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -O2 -DVERSION=\1.12\ -DXS_VERSION=\1.12\ -fPIC -I/opt/openpkg/lib/perl/5.8.8/sun4-solaris/CORE -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 dbdimp.c Running Mkbootstrap for DBD::SQLite () chmod 644 SQLite.bs rm -f blib/arch/auto/DBD/SQLite/SQLite.so /opt/openpkg/bin/cc -Wl,-E -G -L/opt/openpkg/lib SQLite.o dbdimp.o -o blib/arch/auto/DBD/SQLite/SQLite.so \ -L/opt/openpkg/lib -lsqlite3 \ chmod 755 blib/arch/auto/DBD/SQLite/SQLite.so cp SQLite.bs blib/arch/auto/DBD/SQLite/SQLite.bs chmod 644 blib/arch/auto/DBD/SQLite/SQLite.bs ++
Re: perl-dbix 2.20060622 asks for input?
On Mon, Sep 18, 2006, Adam D. Morley wrote: [...] It does indeed have with_dbd_sqlite set to no. Here's the tail end of the output of openpkg build -z -r /var/tmp/opkg perl-dbi (/var/tmp/opkg is a local cache of ftp.openpkg.org, circa last Thursday or so, since we're behind a proxy. without -r, the results are the same): echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm /opt/openpkg/bin/openpkg rpm --define 'with_dbd_sqlite no' --rebuild /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm || exit $? /opt/openpkg/bin/openpkg rpm --force -Uvh /opt/openpkg/RPM/PKG/perl-dbi-5.8.8-2.20060622.sparc64-solaris10-oop.rpm || exit $? echo /var/tmp/opkg/SRC/perl-dbi-5.8.8-2.20060622.src.rpm = $? The problem is: I built the package normally with 2.5. Further, another system running the exact same version of OpenPKG that I'm upgrading from reports the following from openpkg build -z perl-dbi: echo ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm /opt/openpkg/bin/openpkg rpm --rebuild ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm || exit $? /opt/openpkg/bin/openpkg rpm --force -Uvh /opt/openpkg/RPM/PKG/perl-dbi-5.8.7-2.5.0.sparc64-solaris10-oop.rpm || exit $? echo ftp://ftp.openpkg.org/release/2.5/SRC/perl-dbi-5.8.7-2.5.0.src.rpm = $? So somewhere, the option got twiddled. I do know that the src rpm I downloaded for 2.20060622 has the option set correctly at yes. But, upon trying to manually build the package from the source rpm, I get: [root perl-dbi]# openpkg rpm -bb perl-dbi.spec error: Failed build dependencies: sqlite is needed by perl-dbi-5.8.8-2.20060622 So somewhere from the upgrade to 2.5 to 2.20060622, openpkg build seems to have missed the addition of sqlite as a requirement for perl-dbi. Likely because 2.5's perl-dbi has with_dbd_sqlite set to no, so the build script must not consider this possibility? Yes, seems like openpkg build has no possibility here. The default was no in 2.5 and is yes in 2.20060622. So, openpkg build thinks that the no in 2.5 was _manually_ set and correctly forward passes-through this value to the build of 2.20060622. There is real solution for this dependency-change-on-upgrade dilemma as RPM doesn't safe information whether an option was _explicitly_ set or not (and this way is set to the default). But I've now at least added the dependency perl-dbi::with_dbd_sqlite=yes to perl-dbix. I take it the best way to reset the option is to manually build sqlite, then rebuild perl-dbi manually, and then continue with the -ZaKB? [...] You can easily fix those situations with openpkg build -g -Dwith_dbd_sqlite=yes perl-dbi | sh as shown in the manual page which you can read via openpkg man build. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org User Communication List openpkg-users@openpkg.org
