From laurent at elanor.org Mon Jul 2 17:40:58 2012 From: laurent at elanor.org (Laurent Blume) Date: Mon, 02 Jul 2012 17:40:58 +0200 Subject: [csw-users] Selecting 32 or 64 MySQL server Message-ID: <4FF1C10A.9090100@elanor.org> Hello all, I've got a simple questions, but it seems there is no simple answer yet, so I'd like for some feedback first. Problem is simple: both the 32- and 64-bit MySQL servers are delivered by OpenCSW. How to select one? This is very much Solaris 10-centric. I really assume here that S9 and below are dead or deadish, and not really worth bothering about anymore. The current method only point to the 32-bit one. There is no mechanism yet to select the other one. Here are the choices I've thought about: (1) Get rid of the 32-bit version altogether: seriously, this is my preferred way. Solaris 10 supports 32-bit only on x86, and that kind of hardware is seriously outdated by now. Replacing it seems trivial; Pros: Simple and results in less work Cons: Might not be possible, or not useful for all other daemons (2) Use a central or specific configuration file, user-edited, to get the desired value: MySQL5's method already sources a mysql5rc file at different locations. It could contains a variable such as MYSQL_ARCH=[32|64|amd64|sparcv9|...], that could then be used below to start the daemon: if [ -n "${MYSQL_ARCH}" -o "${MYSQL_ARCH}" = "32" ]; then ${BINDIR}/${MYSQL_ARCH}/mysqld_safe ... else ${BINDIR}/mysqld_safe ... fi I believe this could be extended easily to any other daemon by sourcing /etc/opt/csw/csw.conf, and using, if any, the DAEMONNAME_ARCH variable found there (or ${pkgname}_arch?) Pros: Easy to select and provide a list of defaults for, either in a sample csw,conf file or in daemon-specific rc files, and will be kept easily across upgrades; default could easily be set using isainfo -b; it would also allow to have different optimization levels, if ever needed; Cons: Well, there's the need to create and maintain sample files, and to modify existing methods (3) Use isaexec Pros: Transparent, no configuration needed Cons: I've been told Dagobert has 1001 reasons not to use it, I guess one of them is that when it's actually needed to select a specific version, then it's not easy at all (4) Use an SMF property; Pros: It's SMF! It's made with XML! Oracle likes to put everything there! Cons: Same as Pros, plus it needs to be handled properly by the CAS stuff so it's kept across upgrades. In a pinch, I'd favor (2), since it covers more than just my MySQL problem. Thoughts? Laurent From dam at opencsw.org Mon Jul 2 17:44:48 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Jul 2012 17:44:48 +0200 Subject: [csw-users] Selecting 32 or 64 MySQL server In-Reply-To: <4FF1C10A.9090100@elanor.org> References: <4FF1C10A.9090100@elanor.org> Message-ID: Hi Laurent, Am 02.07.2012 um 17:40 schrieb Laurent Blume: > I've got a simple questions, but it seems there is no simple answer yet, so I'd like for some feedback first. > > Problem is simple: both the 32- and 64-bit MySQL servers are delivered by OpenCSW. How to select one? > > This is very much Solaris 10-centric. I really assume here that S9 and below are dead or deadish, and not really worth bothering about anymore. > > The current method only point to the 32-bit one. There is no mechanism yet to select the other one. > > Here are the choices I've thought about: > (1) Get rid of the 32-bit version altogether: seriously, this is my preferred way. Solaris 10 supports 32-bit only on x86, and that kind of hardware is seriously outdated by now. Replacing it seems trivial; > Pros: Simple and results in less work > Cons: Might not be possible, or not useful for all other daemons > > (2) Use a central or specific configuration file, user-edited, to get the desired value: MySQL5's method already sources a mysql5rc file at different locations. It could contains a variable such as MYSQL_ARCH=[32|64|amd64|sparcv9|...], that could then be used below to start the daemon: > if [ -n "${MYSQL_ARCH}" -o "${MYSQL_ARCH}" = "32" ]; then > ${BINDIR}/${MYSQL_ARCH}/mysqld_safe ... > else > ${BINDIR}/mysqld_safe ... > fi > > I believe this could be extended easily to any other daemon by sourcing /etc/opt/csw/csw.conf, and using, if any, the DAEMONNAME_ARCH variable found there (or ${pkgname}_arch?) > Pros: Easy to select and provide a list of defaults for, either in a sample csw,conf file or in daemon-specific rc files, and will be kept easily across upgrades; default could easily be set using isainfo -b; it would also allow to have different optimization levels, if ever needed; > Cons: Well, there's the need to create and maintain sample files, and to modify existing methods > > (3) Use isaexec > Pros: Transparent, no configuration needed > Cons: I've been told Dagobert has 1001 reasons not to use it, I guess one of them is that when it's actually needed to select a specific version, then it's not easy at all > > (4) Use an SMF property; > Pros: It's SMF! It's made with XML! Oracle likes to put everything there! > Cons: Same as Pros, plus it needs to be handled properly by the CAS stuff so it's kept across upgrades. > > > In a pinch, I'd favor (2), since it covers more than just my MySQL problem. > > Thoughts? The downside for (2) is you need to manually select the tools from either /opt/csw/bin or /opt/csw/bin/64 for your selected data model. We had this for OpenLDAP at it is not easy to understand for users. I tend to believe that completely moving to 64 bit would be best (with 32 bit libraries available also). Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 From laurent at elanor.org Mon Jul 2 18:27:43 2012 From: laurent at elanor.org (Laurent Blume) Date: Mon, 02 Jul 2012 18:27:43 +0200 Subject: [csw-users] Selecting 32 or 64 MySQL server In-Reply-To: References: <4FF1C10A.9090100@elanor.org> Message-ID: <4FF1CBFF.7010605@elanor.org> On 07/02/12 17:44, Dagobert Michelsen wrote: > The downside for (2) is you need to manually select the tools from either /opt/csw/bin > or /opt/csw/bin/64 for your selected data model. We had this for OpenLDAP at it is not > easy to understand for users. I don't think it's necessarily a problem. You can set a proper default by: - use the minimal default (32) and tell the user he can set his own - use the kernel default (isainfo -k) and let the user override it if he wants something else In the first case, it would be something like: # Get the default config . /etc/opt/csw/csw.conf # Get the specific config . /etc/opt/csw/mysql5rc # If MYSQLD_ARCH is set to something, use that # architecture name if [ -n "$MYSQLD_ARCH" ]; then MYSQLD_SAFE=${BINDIR}/${MYSQLD_ARCH}/mysqld_safe else # Else just use the minimal 32-bit default MYSQLD_SAFE=${BINDIR}/${MYSQLD_ARCH}/mysqld_safe fi In the second case: # Get the default config . /etc/opt/csw/csw.conf # Get the specific config . /etc/opt/csw/mysql5rc # If MYSQLD_ARCH is not set, use the kernel architecture as default if [ -z "$MYSQLD_ARCH" ]; then MYSQLD_ARCH=$(isainfo -k) fi MYSQLD_SAFE=${BINDIR}/${MYSQLD_ARCH}/mysqld_safe I believe both cases could be easily applied to other daemons. In the first, the 32 bit version could simply be put in bin/. In the second, it's probably better to default it to bin/1386/, but it could be in bin/ if it's easier to keep compatibility or not bother to change recipes. Of course, some additional tests (existence of directories, of binaries) can be added, but that's pretty much trivial as well. > I tend to believe that completely moving to 64 bit would be > best (with 32 bit libraries available also). Certainly agree on that. It would be good for me. Laurent From laurent at elanor.org Mon Jul 2 21:32:18 2012 From: laurent at elanor.org (Laurent Blume) Date: Mon, 02 Jul 2012 21:32:18 +0200 Subject: [csw-users] Selecting 32 or 64 MySQL server In-Reply-To: <4FF1CBFF.7010605@elanor.org> References: <4FF1C10A.9090100@elanor.org> <4FF1CBFF.7010605@elanor.org> Message-ID: <4FF1F742.2030003@elanor.org> Sorry, the first had a copy/paste mistake, but actually, it can be much reduced: # Get the default config . /etc/opt/csw/csw.conf # Get the specific config . /etc/opt/csw/mysql5rc # If MYSQLD_ARCH is set to something, use that # architecture name MYSQLD_SAFE=${BINDIR}/${MYSQLD_ARCH}/mysqld_safe After all, if the variable is empty, // is not very elegant, but perfectly valid :-) Or if keeping the if clause: [...] # Else just use the minimal 32-bit default MYSQLD_SAFE=${BINDIR}/mysqld_safe [...] Laurent On 02/07/2012 18:27, Laurent Blume wrote: > On 07/02/12 17:44, Dagobert Michelsen wrote: >> The downside for (2) is you need to manually select the tools from >> either /opt/csw/bin >> or /opt/csw/bin/64 for your selected data model. We had this for >> OpenLDAP at it is not >> easy to understand for users. > > I don't think it's necessarily a problem. > > You can set a proper default by: > - use the minimal default (32) and tell the user he can set his own > - use the kernel default (isainfo -k) and let the user override it if > he wants something else > > > In the first case, it would be something like: > > # Get the default config > . /etc/opt/csw/csw.conf > # Get the specific config > . /etc/opt/csw/mysql5rc > > # If MYSQLD_ARCH is set to something, use that > # architecture name > if [ -n "$MYSQLD_ARCH" ]; then > MYSQLD_SAFE=${BINDIR}/${MYSQLD_ARCH}/mysqld_safe > else > # Else just use the minimal 32-bit default > MYSQLD_SAFE=${BINDIR}/${MYSQLD_ARCH}/mysqld_safe > fi > > > In the second case: > > # Get the default config > . /etc/opt/csw/csw.conf > # Get the specific config > . /etc/opt/csw/mysql5rc > > # If MYSQLD_ARCH is not set, use the kernel architecture as default > if [ -z "$MYSQLD_ARCH" ]; then > MYSQLD_ARCH=$(isainfo -k) > fi > > MYSQLD_SAFE=${BINDIR}/${MYSQLD_ARCH}/mysqld_safe > > > I believe both cases could be easily applied to other daemons. > In the first, the 32 bit version could simply be put in bin/. > In the second, it's probably better to default it to bin/1386/, but it > could be in bin/ if it's easier to keep compatibility or not bother to > change recipes. > Of course, some additional tests (existence of directories, of binaries) > can be added, but that's pretty much trivial as well. > >> I tend to believe that completely moving to 64 bit would be >> best (with 32 bit libraries available also). > > Certainly agree on that. It would be good for me. > > Laurent > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users From JPClizbe at tx.rr.com Tue Jul 3 15:34:21 2012 From: JPClizbe at tx.rr.com (John Clizbe) Date: Tue, 03 Jul 2012 08:34:21 -0500 Subject: [csw-users] pkgutil says "Catalog is not signed" when using GPG Message-ID: <4FF2F4DD.7000500@tx.rr.com> The error is back. Encountered it last week and thought it might resolve itself. Still getting it today. -bash-3.00# pkgutil -uU => Fetching new catalog and descriptions (http://mirror.opencsw.org/opencsw/unstable/sparc/5.10) if available ... Catalog /var/opt/csw/pkgutil/catalog.mirror.opencsw.org_opencsw_unstable_sparc_5.10 is not signed! Check your mirror settings or disable use_gpg in pkgutil.conf. From maciej at opencsw.org Tue Jul 3 15:45:32 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 3 Jul 2012 14:45:32 +0100 Subject: [csw-users] pkgutil says "Catalog is not signed" when using GPG In-Reply-To: <4FF2F4DD.7000500@tx.rr.com> References: <4FF2F4DD.7000500@tx.rr.com> Message-ID: 2012/7/3 John Clizbe > > The error is back. Encountered it last week and thought it might resolve > itself. Still getting it today. Mea culpa. Sorry for the inconvenience. The signed catalog will be published in 3h. From maciej at opencsw.org Tue Jul 3 17:44:46 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 3 Jul 2012 16:44:46 +0100 Subject: [csw-users] MySQL 5.5 rollback to 5.5.24 Message-ID: Heads up: Due to a serious bug in MySQL 5.5.25 we're rolling back MySQL to 5.5.24 in the unstable catalog. Maciej From eric49933 at gmail.com Tue Jul 3 17:59:46 2012 From: eric49933 at gmail.com (eric eric) Date: Tue, 3 Jul 2012 16:59:46 +0100 Subject: [csw-users] How Can I Determine If My Copies Of gcc And libstdc++ Are Compatible? Message-ID: Hello, How can I determine if my copies of gcc and libstdc++ are compatible? In Brief ======== Our app hangs during static initialization under certain circumstances and the problem seems to coincide with our migration from gcc 4.5.1 to 4.7.1. The stack trace includes paths such as "../gcc-4.5.1/libstdc++" which makes me wonder, maybe our libstdc++ is specific to gcc 4.5.1, maybe we need to upgrade libstdc++? I checked the link below but it does not list gcc 4.7.1: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html In Detail ========= 1) We're on Solaris 10: $ cat /etc/release Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 2) We're on gcc 4.7.1: $ /opt/csw/bin/gcc -v Reading specs from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.7.1/specs COLLECT_GCC=/opt/csw/bin/gcc COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/sparc-sun-solaris2.10/4.7.1/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.7.1/configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib --enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada --enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix --program-suffix=-4.7 --with-as=/opt/csw/bin/gas --with-cloog=/opt/csw --with-gmp=/opt/csw --with-gnu-as --with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw --with-system-zlib=/opt/csw Thread model: posix gcc version 4.7.1 (GCC) 3) We're on libstdc++ 6: $ file /opt/csw/lib/libstdc++.so.6 /opt/csw/lib/libstdc++.so.6: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped How can I get more info about the above file? Minor/Sub version number? ABI/GCC compatibility? 4) Here is the output of ldd on our app: $ ldd myapp libmyapp.so => /path/to/bin/libmyapp.so libboost_unit_test_framework.so.1.48.0 => /path/to/lib/libboost_unit_test_framework.so.1.48.0 libboost_date_time.so.1.48.0 => /path/to/lib/libboost_date_time.so.1.48.0 libboost_filesystem.so.1.48.0 => /path/to/lib/libboost_filesystem.so.1.48.0 libboost_serialization.so.1.48.0 => /path/to/lib/libboost_serialization.so.1.48.0 libboost_system.so.1.48.0 => /path/to/lib/libboost_system.so.1.48.0 libldap.so.5 => /usr/lib/libldap.so.5 libstdc++.so.6 => /opt/csw/gcc4/lib/libstdc++.so.6 libstdc++.so.6 (GLIBCXX_3.4.15) => (version not found) libstdc++.so.6 (CXXABI_1.3) => (version not found) libm.so.2 => /lib/libm.so.2 libgcc_s.so.1 => /opt/csw/gcc4/lib/libgcc_s.so.1 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 librt.so.1 => /lib/librt.so.1 libstdc++.so.6 => /opt/csw/lib/libstdc++.so.6 libsasl.so.1 => /usr/lib/libsasl.so.1 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libmd.so.1 => /lib/libmd.so.1 libnspr4.so => /usr/lib/mps/libnspr4.so libplc4.so => /usr/lib/mps/libplc4.so libnss3.so => /usr/lib/mps/libnss3.so libssl3.so => /usr/lib/mps/libssl3.so libm.so.1 => /lib/libm.so.1 libaio.so.1 => /lib/libaio.so.1 libmp.so.2 => /lib/libmp.so.2 libscf.so.1 => /lib/libscf.so.1 libdl.so.1 => /lib/libdl.so.1 libnssutil3.so => /usr/lib/mps/libnssutil3.so libplds4.so => /usr/lib/mps/libplds4.so libthread.so.1 => /lib/libthread.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 /lib/libm/libm_hwcap1.so.2 /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1 /usr/lib/mps/cpu/sparcv8plus/libnspr_flt4.so 5) Here is the stack trace when our app hangs: (gdb) bt #0 0xfe7ca710 in __lwp_park () from /lib/libc.so.1 #1 0xfe7c459c in cond_sleep_queue () from /lib/libc.so.1 #2 0xfe7c4760 in cond_wait_queue () from /lib/libc.so.1 #3 0xfe7c4ba4 in cond_wait_common () from /lib/libc.so.1 #4 0xfe7c4ca8 in cond_wait () from /lib/libc.so.1 #5 0xfe7c4ce4 in pthread_cond_wait () from /lib/libc.so.1 #6 0xfea4ee3c in __gthread_cond_wait (g=0xfef735d8) at /opt/csw/src/gcc-4.5.1-001/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8/bits/gthr-default.h:862 #7 __gthread_cond_wait_recursive (g=0xfef735d8) at /opt/csw/src/gcc-4.5.1-001/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8/bits/gthr-default.h:876 #8 wait_recursive (g=0xfef735d8) at /opt/csw/src/gcc-4.5.1-001/sparc-sun-solaris2.8/libstdc++-v3/include/ext/concurrence.h:311 #9 __cxxabiv1::__cxa_guard_acquire (g=0xfef735d8) at ../../../../gcc-4.5.1/libstdc++-v3/libsupc++/guard.cc:293 #10 0xfef628c4 in boost::system::generic_category () at libs/system/src/error_code.cpp:424 #11 0xff211f84 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /data/home/bufebs/boost_1_48_0/install/gcc-4.7.1/debug/include/boost/system/error_code.hpp:214 #12 0xff2120cc in _GLOBAL__sub_I_MyApp.cpp(void) () at /path/to/my/code/myapp.cpp:352 #13 0xff2840e4 in __do_global_ctors_aux () from /path/to/my/bin/myapp.so #14 0xff28411c in _init () from /path/to/my/bin/myapp.so #15 0xff3c4bf8 in call_init () from /usr/lib/ld.so.1 #16 0xff3d4be4 in elf_bndr () from /usr/lib/ld.so.1 #17 0xff3b56dc in elf_rtbndr () from /usr/lib/ld.so.1 #18 0xff3b56dc in elf_rtbndr () from /usr/lib/ld.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) As mentioned above the stack trace includes strings like "gcc-4.5.1/libstdc++" which makes me wonder if maybe our libstdc++ is specific to gcc 4.5.1? Maybe we need to upgrade to a libstdc++ for gcc 4.7.1? I would be grateful for any help. Kind Regards, Eric From eric49933 at gmail.com Tue Jul 3 18:36:04 2012 From: eric49933 at gmail.com (eric eric) Date: Tue, 3 Jul 2012 17:36:04 +0100 Subject: [csw-users] How Can I Determine If My Copies Of gcc And libstdc++ Are Compatible? In-Reply-To: References: Message-ID: P.S.... $ ls -l /opt/csw/gcc4/lib/libstdc++.so.6 lrwxrwxrwx 1 root root 19 Oct 19 2011 /opt/csw/gcc4/lib/libstdc++.so.6 -> libstdc++.so.6.0.14 $ mcs -p /opt/csw/gcc4/lib/libstdc++.so.6 /opt/csw/gcc4/lib/libstdc++.so.6: @(#)SunOS 5.8 Generic February 2000 ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.302 /opt/csw/gcc4/lib/libstdc++.so.6: GCC: (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 From dam at opencsw.org Tue Jul 3 18:50:15 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 3 Jul 2012 18:50:15 +0200 Subject: [csw-users] How Can I Determine If My Copies Of gcc And libstdc++ Are Compatible? In-Reply-To: References: Message-ID: <2E1C7C56-1EED-420B-82C7-E17877AEBF1C@opencsw.org> Hi Eric, Am 03.07.2012 um 17:59 schrieb eric eric: > How can I determine if my copies of gcc and libstdc++ are compatible? Short answer: not easily. Looking at your details you are having multiple problems at the same time: 1. You seem to mix packages from Blastwave and OpenCSW. This is problematic due to different flags and compile options. I suggest going through this migration: http://www.opencsw.org/use-it/migrating-from-blastwave-to-opencsw/ 2. You use the Blastwave/OpenCSW libstdc++ where the application was compiled against the /usr/sfw libstdc++ - at least I suppose so because neither bw/ocsw has these interfaces: > libstdc++.so.6 (GLIBCXX_3.4.15) => (version not found) > libstdc++.so.6 (CXXABI_1.3) => (version not found) 3. You have libraries compiled with the old gcc and try to mix them with libs/apps compiled with the new gcc. This can also lead to trouble if the compilers were from different environments (note the multiple inclusions of libstdc++.so.6 at different runpathes), make sure to use a homogenous RPATH setting (-R) during linkage. When you give more details on the compile environment for all things you build your own and pkginfo -x on all included packages I could do a further analysis, but the above issues should get you on the right track for now. Best regards -- Dago > In Brief > ======== > > Our app hangs during static initialization under certain circumstances and the > problem seems to coincide with our migration from gcc 4.5.1 to 4.7.1. The > stack trace includes paths such as "../gcc-4.5.1/libstdc++" which makes me > wonder, maybe our libstdc++ is specific to gcc 4.5.1, maybe we need to upgrade > libstdc++? > > I checked the link below but it does not list gcc 4.7.1: > > http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html > > In Detail > ========= > > 1) We're on Solaris 10: > > $ cat /etc/release > Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC > Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. > Assembled 23 August 2011 > > 2) We're on gcc 4.7.1: > > $ /opt/csw/bin/gcc -v > Reading specs from /opt/csw/lib/gcc/sparc-sun-solaris2.10/4.7.1/specs > COLLECT_GCC=/opt/csw/bin/gcc > COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/sparc-sun-solaris2.10/4.7.1/lto-wrapper > Target: sparc-sun-solaris2.10 > Configured with: > /home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.7.1/configure > --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin > --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share > --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share > --localstatedir=/var/opt/csw --libdir=/opt/csw/lib > --infodir=/opt/csw/share/info --includedir=/opt/csw/include > --mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib > --enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada > --enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix > --program-suffix=-4.7 --with-as=/opt/csw/bin/gas --with-cloog=/opt/csw > --with-gmp=/opt/csw --with-gnu-as --with-included-gettext > --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-libiconv-prefix=/opt/csw > --with-mpfr=/opt/csw --with-ppl=/opt/csw --with-system-zlib=/opt/csw > Thread model: posix > gcc version 4.7.1 (GCC) > > 3) We're on libstdc++ 6: > > $ file /opt/csw/lib/libstdc++.so.6 > /opt/csw/lib/libstdc++.so.6: ELF 32-bit MSB dynamic lib SPARC32PLUS > Version 1, V8+ Required, dynamically linked, not stripped > > How can I get more info about the above file? Minor/Sub version > number? ABI/GCC compatibility? > > 4) Here is the output of ldd on our app: > > $ ldd myapp > libmyapp.so => /path/to/bin/libmyapp.so > libboost_unit_test_framework.so.1.48.0 => > /path/to/lib/libboost_unit_test_framework.so.1.48.0 > libboost_date_time.so.1.48.0 => > /path/to/lib/libboost_date_time.so.1.48.0 > libboost_filesystem.so.1.48.0 => > /path/to/lib/libboost_filesystem.so.1.48.0 > libboost_serialization.so.1.48.0 => > /path/to/lib/libboost_serialization.so.1.48.0 > libboost_system.so.1.48.0 => /path/to/lib/libboost_system.so.1.48.0 > libldap.so.5 => /usr/lib/libldap.so.5 > libstdc++.so.6 => /opt/csw/gcc4/lib/libstdc++.so.6 > libstdc++.so.6 (GLIBCXX_3.4.15) => (version not found) > libstdc++.so.6 (CXXABI_1.3) => (version not found) > libm.so.2 => /lib/libm.so.2 > libgcc_s.so.1 => /opt/csw/gcc4/lib/libgcc_s.so.1 > libpthread.so.1 => /lib/libpthread.so.1 > libc.so.1 => /lib/libc.so.1 > libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 > librt.so.1 => /lib/librt.so.1 > libstdc++.so.6 => /opt/csw/lib/libstdc++.so.6 > libsasl.so.1 => /usr/lib/libsasl.so.1 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libmd.so.1 => /lib/libmd.so.1 > libnspr4.so => /usr/lib/mps/libnspr4.so > libplc4.so => /usr/lib/mps/libplc4.so > libnss3.so => /usr/lib/mps/libnss3.so > libssl3.so => /usr/lib/mps/libssl3.so > libm.so.1 => /lib/libm.so.1 > libaio.so.1 => /lib/libaio.so.1 > libmp.so.2 => /lib/libmp.so.2 > libscf.so.1 => /lib/libscf.so.1 > libdl.so.1 => /lib/libdl.so.1 > libnssutil3.so => /usr/lib/mps/libnssutil3.so > libplds4.so => /usr/lib/mps/libplds4.so > libthread.so.1 => /lib/libthread.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libgen.so.1 => /lib/libgen.so.1 > /lib/libm/libm_hwcap1.so.2 > /platform/SUNW,SPARC-Enterprise/lib/libc_psr.so.1 > /usr/lib/mps/cpu/sparcv8plus/libnspr_flt4.so > > 5) Here is the stack trace when our app hangs: > > (gdb) bt > #0 0xfe7ca710 in __lwp_park () from /lib/libc.so.1 > #1 0xfe7c459c in cond_sleep_queue () from /lib/libc.so.1 > #2 0xfe7c4760 in cond_wait_queue () from /lib/libc.so.1 > #3 0xfe7c4ba4 in cond_wait_common () from /lib/libc.so.1 > #4 0xfe7c4ca8 in cond_wait () from /lib/libc.so.1 > #5 0xfe7c4ce4 in pthread_cond_wait () from /lib/libc.so.1 > #6 0xfea4ee3c in __gthread_cond_wait (g=0xfef735d8) > at /opt/csw/src/gcc-4.5.1-001/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8/bits/gthr-default.h:862 > #7 __gthread_cond_wait_recursive (g=0xfef735d8) > at /opt/csw/src/gcc-4.5.1-001/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8/bits/gthr-default.h:876 > #8 wait_recursive (g=0xfef735d8) at > /opt/csw/src/gcc-4.5.1-001/sparc-sun-solaris2.8/libstdc++-v3/include/ext/concurrence.h:311 > #9 __cxxabiv1::__cxa_guard_acquire (g=0xfef735d8) at > ../../../../gcc-4.5.1/libstdc++-v3/libsupc++/guard.cc:293 > #10 0xfef628c4 in boost::system::generic_category () at > libs/system/src/error_code.cpp:424 > #11 0xff211f84 in __static_initialization_and_destruction_0 > (__initialize_p=1, __priority=65535) > at /data/home/bufebs/boost_1_48_0/install/gcc-4.7.1/debug/include/boost/system/error_code.hpp:214 > #12 0xff2120cc in _GLOBAL__sub_I_MyApp.cpp(void) () > at /path/to/my/code/myapp.cpp:352 > #13 0xff2840e4 in __do_global_ctors_aux () > from /path/to/my/bin/myapp.so > #14 0xff28411c in _init () from /path/to/my/bin/myapp.so > #15 0xff3c4bf8 in call_init () from /usr/lib/ld.so.1 > #16 0xff3d4be4 in elf_bndr () from /usr/lib/ld.so.1 > #17 0xff3b56dc in elf_rtbndr () from /usr/lib/ld.so.1 > #18 0xff3b56dc in elf_rtbndr () from /usr/lib/ld.so.1 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > As mentioned above the stack trace includes strings like > "gcc-4.5.1/libstdc++" which makes me wonder if maybe our libstdc++ is > specific to gcc 4.5.1? Maybe we need to upgrade to a libstdc++ for > gcc 4.7.1? > > I would be grateful for any help. > > Kind Regards, > Eric > _______________________________________________ > users mailing list > users at lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/users From JPClizbe at tx.rr.com Tue Jul 3 20:06:21 2012 From: JPClizbe at tx.rr.com (John Clizbe) Date: Tue, 03 Jul 2012 13:06:21 -0500 Subject: [csw-users] pkgutil says "Catalog is not signed" when using GPG In-Reply-To: References: <4FF2F4DD.7000500@tx.rr.com> Message-ID: <4FF3349D.4010104@tx.rr.com> Maciej (Matchek) Blizi?ski wrote: > 2012/7/3 John Clizbe >> >> The error is back. Encountered it last week and thought it might resolve >> itself. Still getting it today. > > Mea culpa. Sorry for the inconvenience. The signed catalog will be > published in 3h. Got it this time. Thank you for the fast response -John From eric49933 at gmail.com Wed Jul 4 18:33:36 2012 From: eric49933 at gmail.com (eric eric) Date: Wed, 4 Jul 2012 17:33:36 +0100 Subject: [csw-users] How Can I Determine If My Copies Of gcc And libstdc++ Are Compatible? In-Reply-To: References: Message-ID: There are multiple copies of libstdc++.so on our system: $ find /opt/csw/ -name libstdc++.so /opt/csw/lib/libstdc++.so /opt/csw/lib/sparcv9/libstdc++.so /opt/csw/gcc4/lib/libstdc++.so /opt/csw/gcc4/lib/sparcv9/libstdc++.so We were using the 3rd one listed above, which is version 6.0.14, built with Blastwave. The first one is version 6.0.17, built with gcc 4.7.1, the same compiler that we are using. 1A) $ ls -l /opt/csw/gcc4/lib/libstdc++.so lrwxrwxrwx 1 root root 19 Oct 19 2011 /opt/csw/gcc4/lib/libstdc++.so -> libstdc++.so.6.0.14 1B) $ mcs -p /opt/csw/gcc4/lib/libstdc++.so | head -8 /opt/csw/gcc4/lib/libstdc++.so: @(#)SunOS 5.8 Generic February 2000 ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.302 /opt/csw/gcc4/lib/libstdc++.so: GCC: (Blastwave.org Inc. Mon Aug 9 07:10:45 GMT 2010) 4.5.1 2A) $ ls -l /opt/csw/lib/libstdc++.so lrwxrwxrwx 1 root root 19 Jun 20 13:58 /opt/csw/lib/libstdc++.so -> libstdc++.so.6.0.17 2B) $ mcs -p /opt/csw/lib/libstdc++.so | head -8 /opt/csw/lib/libstdc++.so: @(#)SunOS 5.10 Generic January 2005 @(#)SunOS 5.10 Generic January 2005 GCC: (GNU) 4.7.1 Switching to /opt/csw/lib/libstdc++.so fixed a couple of problems: 3) The problem lines from the ldd output went away: libstdc++.so.6 (GLIBCXX_3.4.15) => (version not found) libstdc++.so.6 (CXXABI_1.3) => (version not found) 4) The paths that we see in the stack trace and in the debugger now indicate that libstdc++ was compiled with gcc version 4.7.1: (gdb) s __gthread_once (g=0xfef735d8) at /home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.7.1/libstdc++-v3/libsupc++/guard.cc:75 75 in /home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.7.1/libstdc++-v3/libsupc++/guard.cc From dam at opencsw.org Wed Jul 4 18:42:41 2012 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 4 Jul 2012 18:42:41 +0200 Subject: [csw-users] How Can I Determine If My Copies Of gcc And libstdc++ Are Compatible? In-Reply-To: References: Message-ID: Hi Eric, Am 04.07.2012 um 18:33 schrieb eric eric: > There are multiple copies of libstdc++.so on our system: > > $ find /opt/csw/ -name libstdc++.so > /opt/csw/lib/libstdc++.so > /opt/csw/lib/sparcv9/libstdc++.so > /opt/csw/gcc4/lib/libstdc++.so > /opt/csw/gcc4/lib/sparcv9/libstdc++.so > > We were using the 3rd one listed above, which is version 6.0.14, built > with Blastwave. Please go through the conversion from Blastwave to OpenCSW: http://www.opencsw.org/use-it/migrating-from-blastwave-to-opencsw/ Mixing libs from different compiler versions will cause trouble. The result will be just one used libstdc++ build with the same compiler you are using to build your program. After that we can go through the required libraries. Best regards -- Dago From laurent at elanor.org Wed Jul 4 18:48:37 2012 From: laurent at elanor.org (Laurent Blume) Date: Wed, 04 Jul 2012 18:48:37 +0200 Subject: [csw-users] Selecting 32 or 64 MySQL server In-Reply-To: <4FF1F742.2030003@elanor.org> References: <4FF1C10A.9090100@elanor.org> <4FF1CBFF.7010605@elanor.org> <4FF1F742.2030003@elanor.org> Message-ID: <4FF473E5.5060408@elanor.org> Going forward with this: Here is a drop-in replacement suggestion for /etc/opt/csw/init.d/cswmysql5. It's based on the mysql.server script that is part of the current source (see related https://www.opencsw.org/mantis/view.php?id=4971). It sources /etc/opt/csw/csw.conf, adding those lines allow to change which binary is run. Without them, it just starts the usual 32-bit version. ### # Configure the default and specific architectures # If *_arch is set to "kernel", try to use what isainfo -k suggests # Possible values are i386, amd64, sparcv8, sparcv8plus, sparcv9, ... # Empty means use the default 32 bit binary #default_arch= mysql5_arch=kernel #mysql5_arch=amd64 #mysql5_arch=i386 ### I had to fix some Solaris-specific bugs, one is that bin/amd64/mysqld_safe actually checks for $pwd/libexec/mysqld and run it if it is found. So I changed the ?cd $basedir? to ?cd /opt? to make it fall back on the proper libexec/amd64/mysqld. That really is a MySQL issue rather than OpenCSW, the myswld_safe script prevents defaulting to a bin/$arch/ subdirectory. You can diff it against /opt/csw/share/mysql/mysql.server to see what I did. Nothing terribly complicated, I think. So I think it might be better to have 32-bit mysqld go into libexec/i386/. Not extensively tested, Works On My System is all I can say about it so far, I'm also going to try it on sparc (and run it there if it works). Laurent -------------- next part -------------- #!/bin/sh # Copyright Abandoned 1996 TCX DataKonsult AB & Monty Program KB & Detron HB # This file is public domain and comes with NO WARRANTY of any kind # MySQL daemon start/stop script. # Usually this is put in /etc/init.d (at least on machines SYSV R4 based # systems) and linked to /etc/rc3.d/S99mysql and /etc/rc0.d/K01mysql. # When this is done the mysql server will be started when the machine is # started and shut down when the systems goes down. # Comments to support chkconfig on RedHat Linux # chkconfig: 2345 64 36 # description: A very fast and reliable SQL database engine. # Comments to support LSB init script conventions ### BEGIN INIT INFO # Provides: mysql # Required-Start: $local_fs $network $remote_fs # Should-Start: ypbind nscd ldap ntpd xntpd # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop MySQL # Description: MySQL is a very fast and reliable SQL database engine. ### END INIT INFO # If you install MySQL on some other places than /opt/csw, then you # have to do one of the following things for this script to work: # # - Run this script from within the MySQL installation directory # - Create a /etc/my.cnf file with the following information: # [mysqld] # basedir= # - Add the above to any other configuration file (for example ~/.my.ini) # and copy my_print_defaults to /usr/bin # - Add the path to the mysql-installation-directory to the basedir variable # below. # # If you want to affect other MySQL variables, you should make your changes # in the /etc/my.cnf, ~/.my.cnf or other MySQL configuration files. # If you change base dir, you must also change datadir. These may get # overwritten by settings in the MySQL configuration files. basedir= datadir= # Default value, in seconds, afterwhich the script should timeout waiting # for server start. # Value here is overriden by value in my.cnf. # 0 means don't wait at all # Negative numbers mean to wait indefinitely service_startup_timeout=900 # Lock directory for RedHat / SuSE. lockdir='/var/lock/subsys' lock_file_path="$lockdir/mysql" # The following variables are only set for letting mysql.server find things. # Set some defaults mysqld_pid_file_path= if test -z "$basedir" then basedir=/opt/csw bindir=/opt/csw/bin if test -z "$datadir" then datadir=/var/opt/csw/mysql5 fi sbindir=/opt/csw/libexec libexecdir=/opt/csw/libexec else bindir="$basedir/bin" if test -z "$datadir" then datadir="$basedir/data" fi sbindir="$basedir/libexec" libexecdir="$basedir/libexec" fi # datadir_set is used to determine if datadir was set (and so should be # *not* set inside of the --basedir= handler.) datadir_set= # # Use LSB init script functions for printing messages, if possible # lsb_functions="/lib/lsb/init-functions" if test -f $lsb_functions ; then . $lsb_functions else log_success_msg() { echo " SUCCESS! $@" } log_failure_msg() { echo " ERROR! $@" } fi PATH="/sbin:/usr/sbin:/bin:/usr/bin" export PATH mode=$1 # start or stop [ $# -ge 1 ] && shift other_args="$*" # uncommon, but needed when called from an RPM upgrade action # Expected: "--skip-networking --skip-grant-tables" # They are not checked here, intentionally, as it is the resposibility # of the "spec" file author to give correct arguments only. case `echo "testing\c"`,`echo -n testing` in *c*,-n*) echo_n= echo_c= ;; *c*,*) echo_n=-n echo_c= ;; *) echo_n= echo_c='\c' ;; esac parse_server_arguments() { for arg do case "$arg" in --basedir=*) basedir=`echo "$arg" | sed -e 's/^[^=]*=//'` bindir="$basedir/bin" if test -z "$datadir_set"; then datadir="$basedir/data" fi sbindir="$basedir/sbin" libexecdir="$basedir/libexec" ;; --datadir=*) datadir=`echo "$arg" | sed -e 's/^[^=]*=//'` datadir_set=1 ;; --pid-file=*) mysqld_pid_file_path=`echo "$arg" | sed -e 's/^[^=]*=//'` ;; --service-startup-timeout=*) service_startup_timeout=`echo "$arg" | sed -e 's/^[^=]*=//'` ;; esac done } wait_for_pid () { verb="$1" # created | removed pid="$2" # process ID of the program operating on the pid-file pid_file_path="$3" # path to the PID file. i=0 avoid_race_condition="by checking again" while test $i -ne $service_startup_timeout ; do case "$verb" in 'created') # wait for a PID-file to pop into existence. test -s "$pid_file_path" && i='' && break ;; 'removed') # wait for this PID-file to disappear test ! -s "$pid_file_path" && i='' && break ;; *) echo "wait_for_pid () usage: wait_for_pid created|removed pid pid_file_path" exit 1 ;; esac # if server isn't running, then pid-file will never be updated if test -n "$pid"; then if kill -0 "$pid" 2>/dev/null; then : # the server still runs else # The server may have exited between the last pid-file check and now. if test -n "$avoid_race_condition"; then avoid_race_condition="" continue # Check again. fi # there's nothing that will affect the file. log_failure_msg "The server quit without updating PID file ($pid_file_path)." return 1 # not waiting any more. fi fi echo $echo_n ".$echo_c" i=`expr $i + 1` sleep 1 done if test -z "$i" ; then log_success_msg return 0 else log_failure_msg return 1 fi } ### START OPENCSW ARCHITECTURE SELECTION # Source the configuration # This is used to define the binary architeture to run [ -r /etc/opt/csw/csw.conf ] && . /etc/opt/csw/csw.conf # If the package-specific variable is not set, try the default if [ -z "$mysql5_arch" ]; then if [ -n "$default_arch" ]; then mysql5_arch="$default_arch" fi else # In that specific case, by default, there is no subdir if [ "$mysql5_arch" = "i386" ]; then mysql5_arch="" fi fi # If a value was found if [ -n "$mysql5_arch" ]; then if [ "$mysql5_arch" = "kernel" ]; then # Use the system's default arch mysql5_arch=`isainfo -k` fi # Add the architecture suffix to the executables' directories, if it exists # The binaries themselves are tested below, so the script should fail # mostly gracefully if a non-present arch is set up. if [ -d "$bindir/$mysql5_arch" -a \ -d "$sbindir/$mysql5_arch" -a \ -d "$libexecdir/$mysql5_arch" ]; then bindir="$bindir/$mysql5_arch" sbindir="$sbindir/$mysql5_arch" libexecdir="$libexecdir/$mysql5_arch" fi fi ### END OPENCSW ARCHITECTURE SELECTION # Get arguments from the my.cnf file, # the only group, which is read from now on is [mysqld] if test -x ./bin/my_print_defaults then print_defaults="./bin/my_print_defaults" elif test -x $bindir/my_print_defaults then print_defaults="$bindir/my_print_defaults" elif test -x $bindir/mysql_print_defaults then print_defaults="$bindir/mysql_print_defaults" else # Try to find basedir in /etc/opt/csw/my.cnf conf=/etc/opt/csw/my.cnf print_defaults= if test -r $conf then subpat='^[^=]*basedir[^=]*=\(.*\)$' dirs=`sed -e "/$subpat/!d" -e 's//\1/' $conf` for d in $dirs do d=`echo $d | sed -e 's/[ ]//g'` if test -x "$d/bin/my_print_defaults" then print_defaults="$d/bin/my_print_defaults" break fi if test -x "$d/bin/mysql_print_defaults" then print_defaults="$d/bin/mysql_print_defaults" break fi done fi # Hope it's in the PATH ... but I doubt it test -z "$print_defaults" && print_defaults="my_print_defaults" fi # # Read defaults file from 'basedir'. If there is no defaults file there # check if it's in the old (depricated) place (datadir) and read it from there # extra_args="" if test -r "$basedir/my.cnf" then extra_args="-e $basedir/my.cnf" else if test -r "$datadir/my.cnf" then extra_args="-e $datadir/my.cnf" fi fi parse_server_arguments `$print_defaults $extra_args mysqld server mysql_server mysql.server` # # Set pid file if not given # if test -z "$mysqld_pid_file_path" then mysqld_pid_file_path=$datadir/`hostname`.pid else case "$mysqld_pid_file_path" in /* ) ;; * ) mysqld_pid_file_path="$datadir/$mysqld_pid_file_path" ;; esac fi case "$mode" in 'start') # Start daemon # Safeguard (relative paths, core dumps..) # Changed to /opt for OpenCSW to avoid mysqld_safe picking the 32 bit # binary in libexec/ cd /opt echo $echo_n "Starting MySQL" if test -x $bindir/mysqld_safe then # Give extra arguments to mysqld with the my.cnf file. This script # may be overwritten at next upgrade. $bindir/mysqld_safe --datadir="$datadir" --pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 & wait_for_pid created "$!" "$mysqld_pid_file_path"; return_value=$? # Make lock for RedHat / SuSE if test -w "$lockdir" then touch "$lock_file_path" fi exit $return_value else log_failure_msg "Couldn't find MySQL server ($bindir/mysqld_safe)" fi ;; 'stop') # Stop daemon. We use a signal here to avoid having to know the # root password. if test -s "$mysqld_pid_file_path" then mysqld_pid=`cat "$mysqld_pid_file_path"` if (kill -0 $mysqld_pid 2>/dev/null) then echo $echo_n "Shutting down MySQL" kill $mysqld_pid # mysqld should remove the pid file when it exits, so wait for it. wait_for_pid removed "$mysqld_pid" "$mysqld_pid_file_path"; return_value=$? else log_failure_msg "MySQL server process #$mysqld_pid is not running!" rm "$mysqld_pid_file_path" fi # Delete lock for RedHat / SuSE if test -f "$lock_file_path" then rm -f "$lock_file_path" fi exit $return_value else log_failure_msg "MySQL server PID file could not be found!" fi ;; 'restart') # Stop the service and regardless of whether it was # running or not, start it again. if $0 stop $other_args; then $0 start $other_args else log_failure_msg "Failed to stop running server, so refusing to try to start." exit 1 fi ;; 'reload'|'force-reload') if test -s "$mysqld_pid_file_path" ; then read mysqld_pid < "$mysqld_pid_file_path" kill -HUP $mysqld_pid && log_success_msg "Reloading service MySQL" touch "$mysqld_pid_file_path" else log_failure_msg "MySQL PID file could not be found!" exit 1 fi ;; 'status') # First, check to see if pid file exists if test -s "$mysqld_pid_file_path" ; then read mysqld_pid < "$mysqld_pid_file_path" if kill -0 $mysqld_pid 2>/dev/null ; then log_success_msg "MySQL running ($mysqld_pid)" exit 0 else log_failure_msg "MySQL is not running, but PID file exists" exit 1 fi else # Try to find appropriate mysqld process mysqld_pid=`pgrep $libexecdir/mysqld` if test -z "$mysqld_pid" ; then if test -f "$lock_file_path" ; then log_failure_msg "MySQL is not running, but lock file ($lock_file_path) exists" exit 2 fi log_failure_msg "MySQL is not running" exit 3 else log_failure_msg "MySQL is running but PID file could not be found" exit 4 fi fi ;; *) # usage basename=`basename "$0"` echo "Usage: $basename {start|stop|restart|reload|force-reload|status} [ MySQL server options ]" exit 1 ;; esac exit 0 From maciej at opencsw.org Thu Jul 5 20:33:18 2012 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Jul 2012 19:33:18 +0100 Subject: [csw-users] MySQL 5.5 rollback to 5.5.24 In-Reply-To: References: Message-ID: 2012/7/3 Maciej (Matchek) Blizi?ski : > Heads up: Due to a serious bug in MySQL 5.5.25 we're rolling back > MySQL to 5.5.24 in the unstable catalog. MySQL 5.5.25a with a fix has been released and it's now on its way to the unstable catalog. You should start seeing the update in up to 3h. Maciej From laurent at elanor.org Fri Jul 6 14:52:55 2012 From: laurent at elanor.org (Laurent Blume) Date: Fri, 06 Jul 2012 14:52:55 +0200 Subject: [csw-users] MySQL 5.5 rollback to 5.5.24 In-Reply-To: References: Message-ID: <4FF6DFA7.3000507@elanor.org> On 07/05/12 20:33, Maciej (Matchek) Blizi?ski wrote: > 2012/7/3 Maciej (Matchek) Blizi?ski: >> Heads up: Due to a serious bug in MySQL 5.5.25 we're rolling back >> MySQL to 5.5.24 in the unstable catalog. > > MySQL 5.5.25a with a fix has been released and it's now on its way to > the unstable catalog. You should start seeing the update in up to 3h. Thanks a lot for 5.5.24 in any case. I needed it really quick, and now that it's there, it'll stay for a while. Also, it made my case that OpenCSW is easier to handled change of versions in production :-) Laurent From gshaw at acm.org Fri Jul 13 00:00:24 2012 From: gshaw at acm.org (Guy Shaw) Date: Thu, 12 Jul 2012 15:00:24 -0700 Subject: [csw-users] The "sed-sed-sed" problem Message-ID: <4FFF48F8.60102@acm.org> I am writing to this list, not because I have a problem or question about an OpenCSW package, but because I have a problem that I believe maintainers of OpenCSW packages would have run across, when building OpenCSw packages from an original software tarball. An example ---------- I did not see an OpenCSW package for idutils, so I downloaded the source tarball and built it myself. The usual './configure; make; make install' works just fine, except for the library. I had to tweak the Makefile in the lib sub-directory. The change to make it all work properly is to go from a pipeline of three sed commands to a single sed command with an argument list that is the concatenation of the original three argument lists. I guess the Autotools developers broke up the sed into three stages, because they were worried about systems with wimpy limits on the size of argv. But, I am just guessing. I see no reason why the sed argv1 | sed argv2 | sed argv3 pipeline would not work, but on Solaris, that just hangs. But, the single command: sed argv1 argv2 argv3 works fine. I have tried to come up with smaller, isolated examples that would hang, but with no success. It seems to be only the combination of the Makefile and the shell it uses, and its inability to properly handle the three stage sed-sed-sed pipeline. idutils is just an example. I have seen the same problem with other software that uses GNU Autotools and has a 'lib' sub-directory, and that uses a three stage sed-sed-sed pipeline. Has anyone on this list seen this problem? Is it a well-known problem? -- Guy Shaw From lists at nerdbynature.de Fri Jul 20 07:33:58 2012 From: lists at nerdbynature.de (Christian Kujau) Date: Thu, 19 Jul 2012 22:33:58 -0700 (PDT) Subject: [csw-users] The "sed-sed-sed" problem In-Reply-To: <4FFF48F8.60102@acm.org> References: <4FFF48F8.60102@acm.org> Message-ID: On Thu, 12 Jul 2012 at 15:00, Guy Shaw wrote: > But, I am just guessing. I see no reason why the > > sed argv1 | sed argv2 | sed argv3 > > pipeline would not work, but on Solaris, > that just hangs. Do you have a real example where this hangs? Also, which version of sed are you using? C. -- BOFH excuse #439: Hot Java has gone cold