From rmottola at opencsw.org Sun Mar 1 23:50:59 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 01 Mar 2015 23:50:59 +0100 Subject: gnustep-base configure failure on x86 Message-ID: <54F397D3.9010908@opencsw.org> Hi all, since I need to get gnustep workin on x86, I need to grasp what's wrong. The configure stage fails when it checks for libffi. configure:10328: /opt/csw/bin/gcc-4.9 -o conftest -g -O2 -I/opt/csw/GNUstep/Loc al/Library/Headers -I/opt/csw/GNUstep/Local/Library/Headers -I/opt/csw/GNUstep/S ystem/Library/Headers -I/opt/csw/include -L/opt/csw/GNUstep/Local/Library/Lib raries -L/opt/csw/GNUstep/Local/Library/Libraries -L/opt/csw/GNUstep/System/Libr ary/Libraries conftest.c -L/opt/csw/lib/ffi -lffi -lnsl -lrt -ldl -lpthread - lz >&5 configure:10328: $? = 0 configure:10328: ./conftest ./configure: line 1865: 16587 Segmentation Fault (core dumped) ./conftest$a c_exeext configure:10328: $? = 139 Are there known problems for libffi on x86? or, better, do we know that it works? where can I find conftest? I want to run it in gdb if possible! and is not there are a core file? Riccardo From dam at opencsw.org Mon Mar 2 09:23:09 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 2 Mar 2015 09:23:09 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: <54F397D3.9010908@opencsw.org> References: <54F397D3.9010908@opencsw.org> Message-ID: Hi Riccardo, > Am 01.03.2015 um 23:50 schrieb Riccardo Mottola : > > Hi all, > > since I need to get gnustep workin on x86, I need to grasp what's wrong. > > The configure stage fails when it checks for libffi. > > configure:10328: /opt/csw/bin/gcc-4.9 -o conftest -g -O2 -I/opt/csw/GNUstep/Loc > al/Library/Headers -I/opt/csw/GNUstep/Local/Library/Headers -I/opt/csw/GNUstep/S > ystem/Library/Headers -I/opt/csw/include -L/opt/csw/GNUstep/Local/Library/Lib > raries -L/opt/csw/GNUstep/Local/Library/Libraries -L/opt/csw/GNUstep/System/Libr > ary/Libraries conftest.c -L/opt/csw/lib/ffi -lffi -lnsl -lrt -ldl -lpthread - > lz >&5 > configure:10328: $? = 0 > configure:10328: ./conftest > ./configure: line 1865: 16587 Segmentation Fault (core dumped) ./conftest$a > c_exeext > configure:10328: $? = 139 > > Are there known problems for libffi on x86? Not that I know if. > or, better, do we know that it works? As there are reverse dependencies which habe detected libffi correctly at least it seems so. > where can I find conftest? I want to run it in gdb if possible! > and is not there are a core file? Try to reproduce it manually. The source for conftest is also logger in config.log, then try to compile and pstack. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Mon Mar 2 22:16:06 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 02 Mar 2015 22:16:06 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: References: <54F397D3.9010908@opencsw.org> Message-ID: <54F4D316.9070502@opencsw.org> Hi, Dagobert Michelsen wrote: > Try to reproduce it manually. The source for conftest is also logger in config.log, > then try to compile and pstack. I did something minimal as this: gcc config.ffi.c -L/opt/csw/lib/ffi -lffi ./a.out Segmentation Fault (core dumped) gdb doesn't show anything useful though... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfef74204 in ffi_closure_SYSV_inner () from /opt/csw/lib/libffi.so.5 (gdb) bt #0 0xfef74204 in ffi_closure_SYSV_inner () from /opt/csw/lib/libffi.so.5 #1 0xfef74542 in ffi_closure_SYSV () from /opt/csw/lib/libffi.so.5 #2 0x08050ef4 in main () pstack core core 'core' of 21240: ./a.out fef74204 ffi_closure_SYSV_inner (8047a2c, 8047a40, 0, fef7432a, 8047aac, feffa910) + 24 fef74542 ffi_closure_SYSV (40800000, 40a00000, 3f800000, 41000000) + 1e 08050ef4 main (8050b30, 1, 8047af0) + ea 08050b30 _start (1, 8047be8, 0, 8047bf0, 8047c4a, 8047c5f) + 80 could it be that we have both libffi 4 and 5 ? /opt/csw/lib/libffi.so.4 /opt/csw/lib/libffi.so.4.0.1 /opt/csw/lib/libffi.so.5 /opt/csw/lib/libffi.so.5.0.10 Usually there is a link to the latest version. Can the v4 be uninstalled from unstable10x? But I am just poking around. Riccardo From laurent at opencsw.org Tue Mar 3 10:56:36 2015 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Mar 2015 10:56:36 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: <54F4D316.9070502@opencsw.org> References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> Message-ID: <54F58554.8060302@opencsw.org> Le 2015/03/02 22:16 +0100, Riccardo Mottola a ?crit: > Usually there is a link to the latest version. Can the v4 be uninstalled > from unstable10x? But I am just poking around. > > gcc config.ffi.c -L/opt/csw/lib/ffi -lffi You can gather it from here. Since it did not fail the linking, it means it found the .so in the -L directory. $ ls -l /opt/csw/lib/ffi total 1 lrwxrwxrwx 1 root root 19 Aug 23 2012 libffi.so -> ../libffi.so.5.0.10 > ./a.out > Segmentation Fault (core dumped) That, however, is odd. What it should be saying is that it's not finding the library, since you've not put -R above. That means you have tinkered with LD_LIBRARY_PATH or some such, and you are not telling us. Could you please copy-paste EVERYTHING you've done, instead of trying to hide stuff? What is the output of "ldd a.out"? And also, please post the content of config.ffi.c. > could it be that we have both libffi 4 and 5 ? No. That has nothing to do with it. Laurent From rmottola at opencsw.org Tue Mar 3 21:05:27 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 03 Mar 2015 21:05:27 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: <54F58554.8060302@opencsw.org> References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org> Message-ID: <54F61407.9090109@opencsw.org> Hi Laurent, Laurent Blume wrote: > That, however, is odd. What it should be saying is that it's not finding > the library, since you've not put -R above. That means you have tinkered > with LD_LIBRARY_PATH or some such, and you are not telling us. > > Could you please copy-paste EVERYTHING you've done, instead of trying to > hide stuff? > What is the output of "ldd a.out"? And also, please post the content of > config.ffi.c. > really, I'm not trying to hide anything! I just logged in. I'm not trying tricks, here a transcript, I just redid everything. 502 export TERM=xterm 503 echo $LD_LIBRARY_PATH 504 cd opencsw/gnustep-base/ 505 cd trunk/work/build-isa-pentium_pro/gnustep-base-1.24.7/config 506 ls 507 gcc config.ffi.c -L/opt/csw/lib/ffi -lffi 508 ./a.out rmottola at unstable10x [global]:~ > echo $LD_LIBRARY_PATH (empty) and ./a.out Segmentation Fault (core dumped) ldd a.out libffi.so.5 => /opt/csw/lib/libffi.so.5 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 So the binary is bound to the correct library. The gcc invocation above is a simplified version the full invocation I get in the log is: configure:10307: checking FFI library usage configure:10328: /opt/csw/bin/gcc-4.9 -o conftest -g -O2 -I/opt/csw/GNUstep/Local/Library/Headers -I/opt/csw/GNUstep/Local/Library/Headers -I/opt/csw/GNUstep/System/Library/Headers -I/opt/csw/include -L/opt/csw/GNUstep/Local/Library/Libraries -L/opt/csw/GNUstep/Local/Library/Libraries -L/opt/csw/GNUstep/System/Library/Libraries conftest.c -L/opt/csw/lib/ffi -lffi -lnsl -lrt -ldl -lpthread - lz >&5 I reduced it to the minimum for libffi. Let me note that the same configure check works on sparc (unstable10s). If you don't want to check the package (gnustep-base is checked in) here is the file: http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/config/config.ffi.c?view=markup Thank you for the support, Riccardo From laurent at opencsw.org Tue Mar 3 23:26:30 2015 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 03 Mar 2015 23:26:30 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: <54F61407.9090109@opencsw.org> References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org> <54F61407.9090109@opencsw.org> Message-ID: <54F63516.9090904@opencsw.org> Le 2015/03/03 21:05 +0100, Riccardo Mottola a ?crit: > really, I'm not trying to hide anything! > I just logged in. > I'm not trying tricks, here a transcript, I just redid everything. Apologies, I'm truly stumped. WTF is going on with GCC being a smartass and now having default -R/-I parameters? Ie, how can that line produce a working binary: gcc config.ffi.c -lffi -L/opt/csw/lib/ffi When cc needs that: cc config.ffi.c -L/opt/csw/lib/ffi -R/opt/csw/lib/ffi -lffi -I/opt/csw/include When did GCC acquire that feature?? On the problem, it's definitely libffi.so.5 hich is broken. Building with .4, it works: $ gcc config.ffi.c /opt/csw/lib/libffi.so.4 $ ./a.out $ echo $? 0 Considering the libffi recipe is still using the default obsolete compiler, I can only advise to give it a try with SOS12U4, then with Gcc4. You have a fair use of LD_LIBRARY_PATH there: point it to your newly built lib so a.out picks it up (check with ldd) and you can try it quickly without having to install it. Laurent From maciej at opencsw.org Tue Mar 3 23:55:31 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 3 Mar 2015 22:55:31 +0000 Subject: gnustep-base configure failure on x86 In-Reply-To: <54F63516.9090904@opencsw.org> References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org> <54F61407.9090109@opencsw.org> <54F63516.9090904@opencsw.org> Message-ID: 2015-03-03 22:26 GMT+00:00 Laurent Blume : > When did GCC acquire that feature?? Possibly this: https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/gcc4/trunk/files/0002-default-rpath.diff This was by popular demand, there was a discussion about this somewhere on users@ or maintainers at . I can't find it now. From maciej at opencsw.org Wed Mar 4 00:08:21 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 3 Mar 2015 23:08:21 +0000 Subject: gnustep-base configure failure on x86 In-Reply-To: References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org> <54F61407.9090109@opencsw.org> <54F63516.9090904@opencsw.org> Message-ID: 2015-03-03 22:55 GMT+00:00 Maciej (Matchek) Blizi?ski : > Possibly this: > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/gcc4/trunk/files/0002-default-rpath.diff I found it: http://lists.opencsw.org/pipermail/maintainers/2011-December/015763.html From rmottola at opencsw.org Wed Mar 4 00:19:29 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 04 Mar 2015 00:19:29 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: <54F63516.9090904@opencsw.org> References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org> <54F61407.9090109@opencsw.org> <54F63516.9090904@opencsw.org> Message-ID: <54F64181.3040709@opencsw.org> Laurent Blume wrote: > Le 2015/03/03 21:05 +0100, Riccardo Mottola a ?crit: > > cc config.ffi.c -L/opt/csw/lib/ffi -R/opt/csw/lib/ffi -lffi > -I/opt/csw/include > > When did GCC acquire that feature?? > > > On the problem, it's definitely libffi.so.5 hich is broken. Building > with .4, it works: > > $ gcc config.ffi.c /opt/csw/lib/libffi.so.4 > $ ./a.out > $ echo $? > 0 yes, I tried that too.. so.4 works so.5 not > > Considering the libffi recipe is still using the default obsolete > compiler, I can only advise to give it a try with SOS12U4, then with Gcc4. > > You have a fair use of LD_LIBRARY_PATH there: point it to your newly > built lib so a.out picks it up (check with ldd) and you can try it > quickly without having to install it. So I should try to build locally a package and then point to it? Ok But how can I select different compilers? I see also the receipe forces 64biit, is that correct? $file a.out a.out: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available while the two libffi's appare slighlty different: /opt/csw/lib/libffi.so.4: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped /opt/csw/lib/libffi.so.5: ELF 32-bit LSB dynamic lib 80386 Version 1 [FPU], dynamically linked, not stripped also: dd /opt/csw/lib/libffi.so.4 libgcc_s.so.1 => /opt/csw/lib/i386/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 ldd /opt/csw/lib/libffi.so.5 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 Riccardo From laurent at opencsw.org Wed Mar 4 09:51:28 2015 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 04 Mar 2015 09:51:28 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: <54F64181.3040709@opencsw.org> References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org> <54F61407.9090109@opencsw.org> <54F63516.9090904@opencsw.org> <54F64181.3040709@opencsw.org> Message-ID: <54F6C790.6090702@opencsw.org> Le 2015/03/04 00:19 +0100, Riccardo Mottola a ?crit: > So I should try to build locally a package and then point to it? Ok Basically, you tinker with libffi5 until it works for your binary, then when it does, you update its package. It's not been updated in a while, I'm sure Maciej won't mind if you take it over. You can upgrade it to a newer version, and start by commenting out all the patches, to check if they're still needed. > But how can I select different compilers? GARCOMPILER=GCC4 > I see also the receipe forces 64biit, is that correct? > > $file a.out > a.out: ELF 32-bit LSB executable 80386 Version 1, dynamically > linked, not stripped, no debugging information available > > while the two libffi's appare slighlty different: > > /opt/csw/lib/libffi.so.4: ELF 32-bit LSB dynamic lib 80386 Version > 1, dynamically linked, not stripped > /opt/csw/lib/libffi.so.5: ELF 32-bit LSB dynamic lib 80386 Version > 1 [FPU], dynamically linked, not stripped > > also: > dd /opt/csw/lib/libffi.so.4 > libgcc_s.so.1 => /opt/csw/lib/i386/libgcc_s.so.1 > libc.so.1 => /lib/libc.so.1 > libm.so.2 => /lib/libm.so.2 > > ldd /opt/csw/lib/libffi.so.5 > libc.so.1 => /lib/libc.so.1 > libm.so.2 => /lib/libm.so.2 Nothing to worry about. Laurent From laurent at opencsw.org Wed Mar 4 10:20:47 2015 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 04 Mar 2015 10:20:47 +0100 Subject: gnustep-base configure failure on x86 In-Reply-To: References: <54F397D3.9010908@opencsw.org> <54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org> <54F61407.9090109@opencsw.org> <54F63516.9090904@opencsw.org> Message-ID: <54F6CE6F.50202@opencsw.org> Le 2015/03/04 00:08 +0100, Matchek a ?crit: > 2015-03-03 22:55 GMT+00:00 Maciej (Matchek) Blizi?ski : >> Possibly this: >> https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/gcc4/trunk/files/0002-default-rpath.diff > > I found it: > http://lists.opencsw.org/pipermail/maintainers/2011-December/015763.html > Before I got on that list, then. I note that the discussion says nothing of the implied -I. I can't say I'm happy about the idea. However, since it happened at the time I mostly stopped building with OpenCSW's GCC outside of mgar, and not seen breakage directly caused by that, I guess that'll stay. Laurent From rmottola at opencsw.org Thu Mar 5 12:11:33 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 05 Mar 2015 12:11:33 +0100 Subject: problem building libffi on x86-10 (fatal link error) Message-ID: <54F839E5.8030205@opencsw.org> Hi, as Laurent suggested, I wanted to try to build libffi 5 with dfferent compilers. The first thing I did is build the package "as is" on unstable10x mgar fetch makesum configure build <...> libtool: link: /opt/SUNWspro/bin/cc -G -h libffi.so.5 -o .libs/libffi.so.5.0.10 src/.libs/debug.o src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -lc -m64 -xarch=sse2 -m64 -xarch=sse2 ld: fatal: file src/x86/.libs/unix64.o: section [4].eh_frame: section type is SHT_PROGBITS: expected SHT_AMD64_UNWIND Makefile:790: recipe for target 'libffi.la' failed May I assume that the standard recipe is broken? What could that be? I suppose the package at least used to build The build is happening with the Sun compiler, as expected. This comment in the Makefile is not reassuring: # Fix needed for amd64 using SOS compiler # found at http://software.intel.com/en-us/forums/showthread.php?t=56652 # originally for icc, but at least get the stuff to compile we are on amd64, aren't we? further question: the library is said to be "ELF 32-bit LSB dynamic lib 80386 Version 1 [FPU]' which I think is fie but I think is not amd64. In the makefile I find: BUILD64_LIBS_ONLY = 1 can you shed some light? I am confused. Riccardo From laurent at opencsw.org Thu Mar 5 14:58:46 2015 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 05 Mar 2015 14:58:46 +0100 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F839E5.8030205@opencsw.org> References: <54F839E5.8030205@opencsw.org> Message-ID: <54F86116.1060608@opencsw.org> Le 2015/03/05 12:11 +0100, Riccardo Mottola a ?crit: > Hi, > > as Laurent suggested, I wanted to try to build libffi 5 with dfferent > compilers. > > The first thing I did is build the package "as is" on unstable10x > > mgar fetch makesum configure build > > <...> > libtool: link: /opt/SUNWspro/bin/cc -G -h libffi.so.5 -o > .libs/libffi.so.5.0.10 src/.libs/debug.o src/.libs/prep_cif.o > src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o > src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o > src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -lc -m64 > -xarch=sse2 -m64 -xarch=sse2 > ld: fatal: file src/x86/.libs/unix64.o: section [4].eh_frame: section > type is SHT_PROGBITS: expected SHT_AMD64_UNWIND > Makefile:790: recipe for target 'libffi.la' failed > > May I assume that the standard recipe is broken? What could that be? I > suppose the package at least used to build > The build is happening with the Sun compiler, as expected. Some recipes have been worked on, but never finalized, particularly those of Dago and Maciej, who are overloaded, and this one is old, mgar has much evolved. Don't hesitate to start by removing stuff, like I said, get the latest libffi version, remove the patches, use a recent compiler, check if it builds. > This comment in the Makefile is not reassuring: > # Fix needed for amd64 using SOS compiler > # found at http://software.intel.com/en-us/forums/showthread.php?t=56652 > # originally for icc, but at least get the stuff to compile > > we are on amd64, aren't we? Use GCC4, forget SOS. > further question: the library is said to be "ELF 32-bit LSB dynamic lib > 80386 Version 1 [FPU]' > which I think is fie but I think is not amd64. > In the makefile I find: > BUILD64_LIBS_ONLY = 1 Remove that line. It's only a way to save a few bytes by including only the libraries in a 64 bit build, but it's usually a little pointless IMO. Laurent From rmottola at opencsw.org Thu Mar 5 17:57:34 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 05 Mar 2015 17:57:34 +0100 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F86116.1060608@opencsw.org> References: <54F839E5.8030205@opencsw.org> <54F86116.1060608@opencsw.org> Message-ID: <54F88AFE.1030404@opencsw.org> Hi Laurent Laurent Blume wrote: > Some recipes have been worked on, but never finalized, particularly > those of Dago and Maciej, who are overloaded, and this one is old, mgar > has much evolved. > Don't hesitate to start by removing stuff, like I said, get the latest > libffi version, remove the patches, use a recent compiler, check if it > builds. fine, I had some time and hacked away during some boring meetings :) I upgraded to latest libffi, which incorporated also certain patches (I checked), disabled those that do not apply anymore too. Switched to GCC. It would make 6.0.5 instead of 5.0.10 I got everything to compile and it appears to work for my configure test! I wanted to run the tests (mgar test ?) and re-enabled them. TEST_TARGET = check however when I run mgar test I get: WARNING: could not find 'runtest' so suppose they did nothing. The recipe contains some stuff I do not understand fully that I think needs to be updated: OBSOLETED_BY_CSWlibffi5 = CSWlibffi OBSOLETED_BY_CSWlibffi5-dev = CSWlibffi INCOMPATIBLE_PKGS_CSWlibffi5 = CSWlibffi These just mean that unversioned packaged are obsoleted? These need to be updated to CSWlibffi6 I suppose PACKAGES += CSWlibffi5 PKGFILES_CSWlibffi5 += $(call baseisadirs,$(libdir),libffi\.so\.5(\.\d+)*) SPKG_DESC_CSWlibffi5 += $(DESCRIPTION), libffi.so.5 what do the last two lines do? I just substituted blindly 5 with 6 what is SPKG_*? then we have: PACKAGES += CSWlibffi-dev SPKG_DESC_CSWlibffi-dev = $(DESCRIPTION) - developer package RUNTIME_DEP_PKGS_CSWlibffi-dev += CSWlibffi6 why does it have CSWlibffi-dev and not CSWlibffi6-dev ? Should I commit the receipe as is? I can also post the diff to the list, as you prefer. Thanks, Riccardo From maciej at opencsw.org Thu Mar 5 21:02:29 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 5 Mar 2015 20:02:29 +0000 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F88AFE.1030404@opencsw.org> References: <54F839E5.8030205@opencsw.org> <54F86116.1060608@opencsw.org> <54F88AFE.1030404@opencsw.org> Message-ID: 2015-03-05 16:57 GMT+00:00 Riccardo Mottola : > why does it have CSWlibffi-dev and not CSWlibffi6-dev ? It's because the dev package stays the same, it does not depend on the soname. time T: /opt/csw/lib/libfoo.so ? libfoo.so.1 (CSWfoo-dev) /opt/csw/lib/libfoo.so.1 ? libfoo.so.1.0.0 (CSWlibfoo1) /opt/csw/lib/libfoo.so.1.0.0 (CSWlibfoo1) time T+1: /opt/csw/lib/libfoo.so ? libfoo.so.2 (CSWfoo-dev) /opt/csw/lib/libfoo.so.1 ? libfoo.so.1.0.0 (CSWlibfoo1) /opt/csw/lib/libfoo.so.1.0.0 (CSWlibfoo1) /opt/csw/lib/libfoo.so.2 ? libfoo.so.2.0.0 (CSWlibfoo2) /opt/csw/lib/libfoo.so.2.0.0 (CSWlibfoo2) And so on. CSWlibfooX progresses, CSWfoo-dev stays. Maciej From rmottola at opencsw.org Thu Mar 5 21:04:04 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 05 Mar 2015 21:04:04 +0100 Subject: libffi dependencies problem Message-ID: <54F8B6B4.4040700@opencsw.org> Hi, in my updated, uncommited libffi package, I added: RUNTIME_DEP_PKGS_CSWlibffi6 += CSWlibgcc-s1 because when compiled with gcc, the libffi is linked against this. However, mgar tells me: CHECKPKG_OVERRIDES_CSWlibffi-dev += missing-dependency|CSWlibgcc-s1 CHECKPKG_OVERRIDES_CSWlibffi6 += surplus-dependency|CSWlibgcc-s1 but it makes no sense to add a linked library to "-dev", doesn't it? Riccardo From laurent at opencsw.org Thu Mar 5 21:11:31 2015 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 05 Mar 2015 21:11:31 +0100 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F88AFE.1030404@opencsw.org> References: <54F839E5.8030205@opencsw.org> <54F86116.1060608@opencsw.org> <54F88AFE.1030404@opencsw.org> Message-ID: <54F8B873.2070705@opencsw.org> Le 2015/03/05 17:57 +0100, Riccardo Mottola a ?crit: > I upgraded to latest libffi, which incorporated also certain patches (I > checked), disabled those that do not apply anymore too. Switched to GCC. > It would make 6.0.5 instead of 5.0.10 Not a problem. > I got everything to compile and it appears to work for my configure test! > > I wanted to run the tests (mgar test ?) and re-enabled them. > TEST_TARGET = check > > however when I run mgar test I get: > WARNING: could not find 'runtest' Not mgar test? mgar check? > so suppose they did nothing. > > The recipe contains some stuff I do not understand fully that I think > needs to be updated: > > OBSOLETED_BY_CSWlibffi5 = CSWlibffi > OBSOLETED_BY_CSWlibffi5-dev = CSWlibffi > INCOMPATIBLE_PKGS_CSWlibffi5 = CSWlibffi You'll have to replace the 5 by 6. > These just mean that unversioned packaged are obsoleted? These need to > be updated to CSWlibffi6 I suppose No, it was for transition from the old, pre-standard naming. Packages won't need to be updated (except that to avoid a broken lib, that is). > PACKAGES += CSWlibffi5 > PKGFILES_CSWlibffi5 += $(call baseisadirs,$(libdir),libffi\.so\.5(\.\d+)*) > SPKG_DESC_CSWlibffi5 += $(DESCRIPTION), libffi.so.5 > > what do the last two lines do? I just substituted blindly 5 with 6 > what is SPKG_*? Actually, mgar will surely tell you what to copy-paste. > then we have: > PACKAGES += CSWlibffi-dev > SPKG_DESC_CSWlibffi-dev = $(DESCRIPTION) - developer package > RUNTIME_DEP_PKGS_CSWlibffi-dev += CSWlibffi6 > > why does it have CSWlibffi-dev and not CSWlibffi6-dev ? Because there is only one -dev at a time, pointing to the latest version that is used for all new linking, while there can be several numbered versions of the libs used by previously linked packages. > Should I commit the receipe as is? I can also post the diff to the list, > as you prefer. Run "mgar package" first so it will warn you for missing deps and other issues. Laurent From laurent at opencsw.org Thu Mar 5 21:13:53 2015 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 05 Mar 2015 21:13:53 +0100 Subject: libffi dependencies problem In-Reply-To: <54F8B6B4.4040700@opencsw.org> References: <54F8B6B4.4040700@opencsw.org> Message-ID: <54F8B901.9030303@opencsw.org> Le 2015/03/05 21:04 +0100, Riccardo Mottola a ?crit: > Hi, > > in my updated, uncommited libffi package, I added: > RUNTIME_DEP_PKGS_CSWlibffi6 += CSWlibgcc-s1 > because when compiled with gcc, the libffi is linked against this. > > However, mgar tells me: > > CHECKPKG_OVERRIDES_CSWlibffi-dev += missing-dependency|CSWlibgcc-s1 A -dev packages should contain only headers, some scripts and symlinks, so if it tells you it depends on a lib, it means it improperly contains binaries. Check why. Look at the mgar output, usually it gives the right syntax for the -dev. Maybe theres another package that you should create to contain binaries. > CHECKPKG_OVERRIDES_CSWlibffi6 += surplus-dependency|CSWlibgcc-s1 > > but it makes no sense to add a linked library to "-dev", doesn't it? > > Riccardo > From maciej at opencsw.org Thu Mar 5 21:39:41 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Thu, 05 Mar 2015 20:39:41 +0000 Subject: libffi dependencies problem References: <54F8B6B4.4040700@opencsw.org> <54F8B901.9030303@opencsw.org> Message-ID: A good link to check is http://buildfarm.opencsw.org/pkgdb/srv4/ - you can click your package and inspect the contents as seen by checkpkg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Thu Mar 5 22:40:08 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 5 Mar 2015 22:40:08 +0100 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F8B873.2070705@opencsw.org> References: <54F839E5.8030205@opencsw.org> <54F86116.1060608@opencsw.org> <54F88AFE.1030404@opencsw.org> <54F8B873.2070705@opencsw.org> Message-ID: Hi folks, > Am 05.03.2015 um 21:11 schrieb Laurent Blume : > > Le 2015/03/05 17:57 +0100, Riccardo Mottola a ?crit: >> I upgraded to latest libffi, which incorporated also certain patches (I >> checked), disabled those that do not apply anymore too. Switched to GCC. >> It would make 6.0.5 instead of 5.0.10 > > Not a problem. > >> I got everything to compile and it appears to work for my configure test! >> >> I wanted to run the tests (mgar test ?) and re-enabled them. >> TEST_TARGET = check >> >> however when I run mgar test I get: >> WARNING: could not find 'runtest' > > Not mgar test? mgar check? > >> so suppose they did nothing. >> >> The recipe contains some stuff I do not understand fully that I think >> needs to be updated: >> >> OBSOLETED_BY_CSWlibffi5 = CSWlibffi >> OBSOLETED_BY_CSWlibffi5-dev = CSWlibffi >> INCOMPATIBLE_PKGS_CSWlibffi5 = CSWlibffi > > You'll have to replace the 5 by 6. No, these should be ripped out. This is because a long time ago everything was in CSWlibffi and packages depended on it. Then libffi.so.5 was split and the existing packages should still find their library. As CSWlibffi is still in the catalog as stub depending on .so.5 it stays where it is. Just remove the three lines. >> These just mean that unversioned packaged are obsoleted? These need to >> be updated to CSWlibffi6 I suppose > > No, it was for transition from the old, pre-standard naming. Packages > won't need to be updated (except that to avoid a broken lib, that is). > >> PACKAGES += CSWlibffi5 >> PKGFILES_CSWlibffi5 += $(call baseisadirs,$(libdir),libffi\.so\.5(\.\d+)*) >> SPKG_DESC_CSWlibffi5 += $(DESCRIPTION), libffi.so.5 >> >> what do the last two lines do? I just substituted blindly 5 with 6 >> what is SPKG_*? > > Actually, mgar will surely tell you what to copy-paste. The problem is that the new .so.6 library got in the catchall package and CSWlibffi5 was empty as more like libffi6 was generated. >> then we have: >> PACKAGES += CSWlibffi-dev >> SPKG_DESC_CSWlibffi-dev = $(DESCRIPTION) - developer package >> RUNTIME_DEP_PKGS_CSWlibffi-dev += CSWlibffi6 >> >> why does it have CSWlibffi-dev and not CSWlibffi6-dev ? > > Because there is only one -dev at a time, pointing to the latest version > that is used for all new linking, while there can be several numbered > versions of the libs used by previously linked packages. > >> Should I commit the receipe as is? I can also post the diff to the list, >> as you prefer. > > Run "mgar package" first so it will warn you for missing deps and other > issues. Yep, or ?repackage?. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Fri Mar 6 09:41:33 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 06 Mar 2015 09:41:33 +0100 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F8B873.2070705@opencsw.org> References: <54F839E5.8030205@opencsw.org> <54F86116.1060608@opencsw.org> <54F88AFE.1030404@opencsw.org> <54F8B873.2070705@opencsw.org> Message-ID: <54F9683D.5030900@opencsw.org> Hi, Laurent Blume wrote: >> >I wanted to run the tests (mgar test ?) and re-enabled them. >> >TEST_TARGET = check >> > >> >however when I run mgar test I get: >> >WARNING: could not find 'runtest' > Not mgar test? mgar check? > mgar check gmake: *** No rule to make target 'check'. Stop. But I think I found the gotcha in readme: "To ensure that libffi is working as advertised, type "make check". This will require that you have DejaGNU installed." Riccardo From grzemba at contac-dt.de Fri Mar 6 10:06:23 2015 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Fri, 06 Mar 2015 10:06:23 +0100 Subject: OpenCSW technical Wintercamp in Ilmenau In-Reply-To: References: Message-ID: Hi, I guess we have a date for the winter camp. It will be Friday, 20. March to Sunday, 22. March in Ilmenau. The main topics should be online presence and IPS. The visit of Fraunhofer audio labs is planed for March, 20 16:00 Uhr. For furthewr details see also: http://wiki.opencsw.org/wintercamp-2014 and please add your name to the list of attendees. Hotel recommendation: Hotel Tanne, 62? (HRS) . Best regards Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at opencsw.org Fri Mar 6 12:00:27 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 06 Mar 2015 12:00:27 +0100 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F8B873.2070705@opencsw.org> References: <54F839E5.8030205@opencsw.org> <54F86116.1060608@opencsw.org> <54F88AFE.1030404@opencsw.org> <54F8B873.2070705@opencsw.org> Message-ID: <54F988CB.5000805@opencsw.org> Hi Laurent and Dago, I think I made quite some big progress. The only warning I get now is : CHECKPKG_OVERRIDES_CSWlibffi-dev += wrong-docdir|expected=/opt/csw/shared/doc/libffi_dev/...|in-package=/opt/csw/share/doc/libffi_stub/license Strangely I get this only on x86 and not sparc. What can I do about this? Laurent Blume wrote: > Because there is only one -dev at a time, pointing to the latest version > that is used for all new linking, while there can be several numbered > versions of the libs used by previously linked packages. Clear, there was some trickery to define what went into dev and not and it still had "5", thus the whole libraries went inside the dev package and thus the warnings. Look here: http://buildfarm.opencsw.org/pkgdb/srv4/61c1ae8cdb575ab07b28220098f08944/ This looks fine, except his: 1 s none /opt/csw/lib/ffi/libffi.so=../libffi.so.6.0.4 I think this means that the "link" is in dev and not runtime. Is that correct? I suppose it can be considered something useful during linking and thus for developers. Given that, may I commit what I have now? I have further questions about some parts in this receipe! Riccardo PS: Latest libffi says in the documentation that sun/oracle compiler is supported. Should I make a test? is its use preferred over GCC? From pfelecan at opencsw.org Fri Mar 6 14:07:51 2015 From: pfelecan at opencsw.org (Peter FELECAN) Date: Fri, 06 Mar 2015 14:07:51 +0100 Subject: problem building libffi on x86-10 (fatal link error) In-Reply-To: <54F988CB.5000805@opencsw.org> (Riccardo Mottola's message of "Fri, 06 Mar 2015 12:00:27 +0100") References: <54F839E5.8030205@opencsw.org> <54F86116.1060608@opencsw.org> <54F88AFE.1030404@opencsw.org> <54F8B873.2070705@opencsw.org> <54F988CB.5000805@opencsw.org> Message-ID: Riccardo Mottola writes: > Hi Laurent and Dago, > > I think I made quite some big progress. > > The only warning I get now is : > CHECKPKG_OVERRIDES_CSWlibffi-dev += > wrong-docdir|expected=/opt/csw/shared/doc/libffi_dev/...|in-package=/opt/csw/share/doc/libffi_stub/license > > Strangely I get this only on x86 and not sparc. What can I do about this? > > Laurent Blume wrote: >> Because there is only one -dev at a time, pointing to the latest version >> that is used for all new linking, while there can be several numbered >> versions of the libs used by previously linked packages. > Clear, there was some trickery to define what went into dev and not > and it still had "5", thus the whole libraries went inside the dev > package and thus the warnings. > > Look here: > http://buildfarm.opencsw.org/pkgdb/srv4/61c1ae8cdb575ab07b28220098f08944/ > > This looks fine, except his: > > 1 s none /opt/csw/lib/ffi/libffi.so=../libffi.so.6.0.4 > > I think this means that the "link" is in dev and not runtime. Is that > correct? I suppose it can be considered something useful during > linking and thus for developers. This is nominal, i.e., as it must be. > Given that, may I commit what I have now? I have further questions > about some parts in this receipe! > > Riccardo > > PS: Latest libffi says in the documentation that sun/oracle compiler > is supported. Should I make a test? is its use preferred over GCC? We decided to make the transition toward GCC, consequently, there is no need to waste your time with the "sun/oracle" compiler. -- Peter From rmottola at opencsw.org Sat Mar 7 10:02:25 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 07 Mar 2015 10:02:25 +0100 Subject: libffi 3.2.1 sol10 ready Message-ID: <54FABEA1.3040008@opencsw.org> Hi, I have the new libffi 3.2.1 packages compiled with gcc ready: Jolly good! All checks passed, no error tags reported. And I have these: libffi6-3.2.1,REV=2015.03.07-SunOS5.10-i386-CSW.pkg.gz libffi6-3.2.1,REV=2015.03.07-SunOS5.10-sparc-CSW.pkg.gz libffi_dev-3.2.1,REV=2015.03.07-SunOS5.10-i386-CSW.pkg.gz libffi_dev-3.2.1,REV=2015.03.07-SunOS5.10-sparc-CSW.pkg.gz however, when I upload (just by chance I started with the first file), I get an error: There is a problem with the presented file list. * CheckpkgTag(None, 'sparc-SunOS5.10-missing', 'libffi6') Riccardo From rmottola at opencsw.org Sat Mar 7 10:05:14 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 07 Mar 2015 10:05:14 +0100 Subject: libffi on solaris 9 Message-ID: <54FABF4A.50701@opencsw.org> Hi, are the solaris 9 machines under maintenance? I wanted to check if my new libffi builds on solaris 9 On sparc, configure starts, checking whether make supports nested variables... yes checking for gcc... /opt/csw/bin/gcc-4.9 checking whether the C compiler works... no configure: error: in `/home/rmottola/opencsw/libffi/trunk/work/build-isa-sparcv8/libffi-3.2.1/sparc-sun-solaris2.9': configure: error: C compiler cannot create executables See `config.log' for more details but I don't think we have gcc 4.9 on solaris 9? gcc points to 4.6! On intel instead (unstable9x) -bash-4.3$ mgar -bash: mgar: command not found No mgar? :) :) Riccardo From maciej at opencsw.org Sat Mar 7 10:05:23 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Mar 2015 09:05:23 +0000 Subject: libffi 3.2.1 sol10 ready In-Reply-To: <54FABEA1.3040008@opencsw.org> References: <54FABEA1.3040008@opencsw.org> Message-ID: 2015-03-07 9:02 GMT+00:00 Riccardo Mottola : > There is a problem with the presented file list. > * CheckpkgTag(None, 'sparc-SunOS5.10-missing', 'libffi6') Show how you upload. From rmottola at opencsw.org Sat Mar 7 10:56:25 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 07 Mar 2015 10:56:25 +0100 Subject: libffi 3.2.1 sol10 ready In-Reply-To: References: <54FABEA1.3040008@opencsw.org> Message-ID: <54FACB49.7000609@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > 2015-03-07 9:02 GMT+00:00 Riccardo Mottola: >> >There is a problem with the presented file list. >> >* CheckpkgTag(None, 'sparc-SunOS5.10-missing', 'libffi6') > Show how you upload. quite brutally: csw-upload-pkg libffi6-3.2.1,REV=2015.03.07-SunOS5.10-i386-CSW.pkg.gz Riccardo From maciej at opencsw.org Sat Mar 7 11:09:38 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Mar 2015 10:09:38 +0000 Subject: libffi 3.2.1 sol10 ready In-Reply-To: <54FACB49.7000609@opencsw.org> References: <54FABEA1.3040008@opencsw.org> <54FACB49.7000609@opencsw.org> Message-ID: 2015-03-07 9:56 GMT+00:00 Riccardo Mottola : > quite brutally: > > csw-upload-pkg libffi6-3.2.1,REV=2015.03.07-SunOS5.10-i386-CSW.pkg.gz Why exclude the sparc package? From rmottola at opencsw.org Sat Mar 7 11:31:47 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 07 Mar 2015 11:31:47 +0100 Subject: libffi 3.2.1 sol10 ready In-Reply-To: References: <54FABEA1.3040008@opencsw.org> <54FACB49.7000609@opencsw.org> Message-ID: <54FAD393.9060706@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > 2015-03-07 9:56 GMT+00:00 Riccardo Mottola : >> quite brutally: >> >> csw-upload-pkg libffi6-3.2.1,REV=2015.03.07-SunOS5.10-i386-CSW.pkg.gz > Why exclude the sparc package? just didn't know that I should upload them in pairs. I did and it worked. The new packages are now available! if someone can tell me what's wrong with the sol. 9 machines, I'll try my luck there too. Riccardo From maciej at opencsw.org Sat Mar 7 11:38:21 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Mar 2015 10:38:21 +0000 Subject: libffi 3.2.1 sol10 ready In-Reply-To: <54FAD393.9060706@opencsw.org> References: <54FABEA1.3040008@opencsw.org> <54FACB49.7000609@opencsw.org> <54FAD393.9060706@opencsw.org> Message-ID: 2015-03-07 10:31 GMT+00:00 Riccardo Mottola : > just didn't know that I should upload them in pairs. I did and it worked. We had a problem where people would build a package for 2 architectures, and forget to upload one of them - so we have check to make it harder to do wrong. > The new packages are now available! Cool! > if someone can tell me what's wrong with the sol. 9 machines, I'll try my > luck there too. Haven't checked, best place to poke people about buildfarm, is buildfarm at . About mgar, check if /opt/csw/bin/mgar exists - uninstalled package, or a problem with $PATH? From maciej at opencsw.org Sat Mar 7 11:39:43 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 7 Mar 2015 10:39:43 +0000 Subject: libffi on solaris 9 In-Reply-To: <54FABF4A.50701@opencsw.org> References: <54FABF4A.50701@opencsw.org> Message-ID: 2015-03-07 9:05 GMT+00:00 Riccardo Mottola : > but I don't think we have gcc 4.9 on solaris 9? gcc points to 4.6! 4.6 is the newest GCC we managed to build on 5.9. > On intel instead (unstable9x) > > -bash-4.3$ mgar > -bash: mgar: command not found > > No mgar? :) :) Or $PATH? We don't add /opt/csw/bin to PATH system-wide. From laurent at opencsw.org Sat Mar 7 13:41:15 2015 From: laurent at opencsw.org (Laurent Blume) Date: Sat, 07 Mar 2015 13:41:15 +0100 Subject: libffi on solaris 9 In-Reply-To: References: <54FABF4A.50701@opencsw.org> Message-ID: <54FAF1EB.1080708@opencsw.org> Le 2015/03/07 11:39 +0100, Matchek a ?crit: > Or $PATH? We don't add /opt/csw/bin to PATH system-wide. > Yes, it's done by Baltic Online stuff in /etc/environment, which is not installed on unstable9x. Definitely a request for buildfarm at . Laurent From rmottola at opencsw.org Sat Mar 7 18:39:57 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 07 Mar 2015 18:39:57 +0100 Subject: libffi on solaris 9 In-Reply-To: References: <54FABF4A.50701@opencsw.org> Message-ID: <54FB37ED.60204@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > 2015-03-07 9:05 GMT+00:00 Riccardo Mottola: >> >but I don't think we have gcc 4.9 on solaris 9? gcc points to 4.6! > 4.6 is the newest GCC we managed to build on 5.9. > exactly! and that is what I see when I look in bin and with gcc --version However configure seems to pickup a non-existent compiler: checking for gcc... /opt/csw/bin/gcc-4.9 and then I get: checking whether the C compiler works... no Obvious.... Riccardo From dam at opencsw.org Sat Mar 7 18:41:56 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 7 Mar 2015 18:41:56 +0100 Subject: libffi on solaris 9 In-Reply-To: <54FAF1EB.1080708@opencsw.org> References: <54FABF4A.50701@opencsw.org> <54FAF1EB.1080708@opencsw.org> Message-ID: <93778141-314A-4EFB-8631-1045E67642C9@opencsw.org> Hi, > Am 07.03.2015 um 13:41 schrieb Laurent Blume : > > Le 2015/03/07 11:39 +0100, Matchek a ?crit: >> Or $PATH? We don't add /opt/csw/bin to PATH system-wide. > > Yes, it's done by Baltic Online stuff in /etc/environment, which is not > installed on unstable9x. > > Definitely a request for buildfarm at . Done. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Sat Mar 7 18:48:04 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 7 Mar 2015 18:48:04 +0100 Subject: libffi on solaris 9 In-Reply-To: <54FB37ED.60204@opencsw.org> References: <54FABF4A.50701@opencsw.org> <54FB37ED.60204@opencsw.org> Message-ID: <475E0804-C60F-4686-9F16-CCD2132E6169@opencsw.org> Hi Riccardo, > Am 07.03.2015 um 18:39 schrieb Riccardo Mottola : > > Maciej (Matchek) Blizi?ski wrote: >> 2015-03-07 9:05 GMT+00:00 Riccardo Mottola: >>> >but I don't think we have gcc 4.9 on solaris 9? gcc points to 4.6! >> 4.6 is the newest GCC we managed to build on 5.9. >> > exactly! and that is what I see when I look in bin and with gcc --version > > However configure seems to pickup a non-existent compiler: > checking for gcc... /opt/csw/bin/gcc-4.9 > > and then I get: > checking whether the C compiler works... no > > Obvious.... I added GCC4_VERSION = 4.6 to /etc/opt/csw/garrc, but as you see nobody has bothered compiling anything with gcc on Solaris 9 for at least a year? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Sat Mar 7 21:13:39 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 07 Mar 2015 21:13:39 +0100 Subject: libffi on solaris 9 In-Reply-To: <475E0804-C60F-4686-9F16-CCD2132E6169@opencsw.org> References: <54FABF4A.50701@opencsw.org> <54FB37ED.60204@opencsw.org> <475E0804-C60F-4686-9F16-CCD2132E6169@opencsw.org> Message-ID: <54FB5BF3.8040906@opencsw.org> Hi, solaris 9 packages built and uploaded! Dago, can you install them on all respective 4 machines? Riccardo From dam at opencsw.org Sat Mar 7 22:08:59 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 7 Mar 2015 22:08:59 +0100 Subject: libffi on solaris 9 In-Reply-To: <54FB5BF3.8040906@opencsw.org> References: <54FABF4A.50701@opencsw.org> <54FB37ED.60204@opencsw.org> <475E0804-C60F-4686-9F16-CCD2132E6169@opencsw.org> <54FB5BF3.8040906@opencsw.org> Message-ID: Hi Riccardo, > Am 07.03.2015 um 21:13 schrieb Riccardo Mottola : > > solaris 9 packages built and uploaded! > > Dago, can you install them on all respective 4 machines? Sure, done. Please mail to buildfarm@ next time. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Sun Mar 8 10:35:51 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 08 Mar 2015 10:35:51 +0100 Subject: missing libffi.so master link Message-ID: <54FC17F7.5020403@opencsw.org> Hi, now we have a shiny new libffi package on all 4 platform (9/10 x86/sparc) combinations! However, I cannot build gnustep-base: ld: fatal: library -lffi: not found ld: fatal: file processing errors. No output written to conftest Checking on unstable10x, I see that there indeed is no master libffi.so file: ls -l /opt/csw/lib/libffi*lrwxrwxrwx 1 root root 15 Oct 3 2013 /opt/csw/lib/libffi.so.4 -> libffi.so.4.0.1 -rwxr-xr-x 1 root bin 89036 Sep 26 2013 /opt/csw/lib/libffi.so.4.0.1 lrwxrwxrwx 1 root root 16 Aug 23 2012 /opt/csw/lib/libffi.so.5 -> libffi.so.5.0.10 -rwxr-xr-x 1 root bin 36128 Jun 25 2011 /opt/csw/lib/libffi.so.5.0.10 lrwxrwxrwx 1 root root 15 Mar 7 22:30 /opt/csw/lib/libffi.so.6 -> libffi.so.6.0.4 -rwxr-xr-x 1 root bin 31892 Mar 5 17:56 /opt/csw/lib/libffi.so.6.0.4 This file should be supplied by libffi-dev package and: http://buildfarm.opencsw.org/pkgdb/srv4/3900427c3176715f8c75598c20df0cd0/ shows there is. What is wrong? the dev packae? Or something went wrong during installation? Thanks, Riccardo From laurent at opencsw.org Sun Mar 8 12:11:24 2015 From: laurent at opencsw.org (Laurent Blume) Date: Sun, 08 Mar 2015 12:11:24 +0100 Subject: missing libffi.so master link In-Reply-To: <54FC17F7.5020403@opencsw.org> References: <54FC17F7.5020403@opencsw.org> Message-ID: <54FC2E5C.6020902@opencsw.org> Le 2015/03/08 10:35 +0100, Riccardo Mottola a ?crit: > Hi, > > now we have a shiny new libffi package on all 4 platform (9/10 > x86/sparc) combinations! > > However, I cannot build gnustep-base: > > ld: fatal: library -lffi: not found 1 s none /opt/csw/lib/>>>>ffi<<< References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> Message-ID: <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> Hi Laurent, > Am 08.03.2015 um 12:11 schrieb Laurent Blume : > > Le 2015/03/08 10:35 +0100, Riccardo Mottola a ?crit: >> Hi, >> >> now we have a shiny new libffi package on all 4 platform (9/10 >> x86/sparc) combinations! >> >> However, I cannot build gnustep-base: >> >> ld: fatal: library -lffi: not found > > 1 s none /opt/csw/lib/>>>>ffi<<< > It's not in the standard lib/ because there is another different library > with the same name. So you need to add that one to -L in your recipe > (but in that case, not -R, since the actual .so.x are in lib/). I vaguely remember that there were two libffi, one with gcc and another one as a separate project. Is this still the case? I also vaguely remember that the issue was resolved, but can?t find a reference right now. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From laurent at opencsw.org Sun Mar 8 12:31:14 2015 From: laurent at opencsw.org (Laurent Blume) Date: Sun, 08 Mar 2015 12:31:14 +0100 Subject: missing libffi.so master link In-Reply-To: <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> Message-ID: <54FC3302.6000307@opencsw.org> Le 2015/03/08 12:14 +0100, Dagobert Michelsen a ?crit: > I vaguely remember that there were two libffi, one with gcc and another one as a separate > project. Is this still the case? I also vaguely remember that the issue was resolved, > but can?t find a reference right now. I've not looked much into it, Just noticed that the .so of that libffi is in a different subdir. I see no .so for the GCC one, nor dependency on it, so it looks basically useless. I have no idea what either lib does, nor why they've got the same name, and 30 seconds of duckduckgoing did not turn up much. Riccardo: you missed the 64 bit lib in your updated package, it has only 32 bit libs. You'd better fix it quickly, as it will break building some deps. Laurent From maciej at opencsw.org Sun Mar 8 12:47:29 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Mar 2015 11:47:29 +0000 Subject: missing libffi.so master link In-Reply-To: <54FC3302.6000307@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> Message-ID: 2015-03-08 11:31 GMT+00:00 Laurent Blume : > I've not looked much into it, Just noticed that the .so of that libffi > is in a different subdir. I see no .so for the GCC one, nor dependency > on it, so it looks basically useless. Yes, it is useless now. This quirk comes from the times when we couldn't, or didn't want to remove gcc3 from the catalog. Riccardo, I'd suggest moving the .so file back to /opt/csw/lib. From rmottola at opencsw.org Sun Mar 8 14:23:46 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 08 Mar 2015 14:23:46 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> Message-ID: <54FC4D62.7000304@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > 2015-03-08 11:31 GMT+00:00 Laurent Blume : >> I've not looked much into it, Just noticed that the .so of that libffi >> is in a different subdir. I see no .so for the GCC one, nor dependency >> on it, so it looks basically useless. > Yes, it is useless now. This quirk comes from the times when we > couldn't, or didn't want to remove gcc3 from the catalog. Riccardo, > I'd suggest moving the .so file back to /opt/csw/lib. I will do that later today for sure stay tuned for new packages. Riccardo From rmottola at opencsw.org Sun Mar 8 14:27:09 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 08 Mar 2015 14:27:09 +0100 Subject: missing libffi.so master link In-Reply-To: <54FC3302.6000307@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> Message-ID: <54FC4E2D.4090903@opencsw.org> Hi, Laurent Blume wrote: > Riccardo: > you missed the 64 bit lib in your updated package, it has only 32 bit > libs. You'd better fix it quickly, as it will break building some deps. sorry for breaking things. But how do I build both variants? I just "updated" an existing receipe. The only thing that looks in the topic is that I removed BUILD64_LIBS_ONLY = 1 but I suppose we want both versions, don't we? What is needed in the receipe? Riccardo From maciej at opencsw.org Sun Mar 8 14:34:16 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Mar 2015 13:34:16 +0000 Subject: missing libffi.so master link In-Reply-To: <54FC4E2D.4090903@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> Message-ID: 2015-03-08 13:27 GMT+00:00 Riccardo Mottola : > BUILD64_LIBS_ONLY = 1 > > but I suppose we want both versions, don't we? The word "only" applies to libs, not to 64. Natural language is confusing! From dam at opencsw.org Sun Mar 8 14:59:21 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Sun, 8 Mar 2015 14:59:21 +0100 Subject: missing libffi.so master link In-Reply-To: <54FC4E2D.4090903@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> Message-ID: Hi Riccardo, > Am 08.03.2015 um 14:27 schrieb Riccardo Mottola : > > Laurent Blume wrote: >> Riccardo: >> you missed the 64 bit lib in your updated package, it has only 32 bit >> libs. You'd better fix it quickly, as it will break building some deps. > sorry for breaking things. But how do I build both variants? I just "updated" an existing receipe. > > The only thing that looks in the topic is that I removed > > BUILD64_LIBS_ONLY = 1 The bracketing is BUILD64_(LIBS_ONLY) which should mean only libs in 32+64 bit and binaries in 32 bit only. > but I suppose we want both versions, don't we? Libraries always in 32 and 64, you?ll never know how needs the library. > What is needed in the receipe? Just put it back it, the other directive is BUILD64 = 1 which puts both libs and binaries into the package. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From laurent at opencsw.org Sun Mar 8 15:04:52 2015 From: laurent at opencsw.org (Laurent Blume) Date: Sun, 08 Mar 2015 15:04:52 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> Message-ID: <54FC5704.8070806@opencsw.org> Le 2015/03/08 14:59 +0100, Dagobert Michelsen a ?crit: > BUILD64 = 1 Only this one is enough IMO. Laurent From maciej at opencsw.org Sun Mar 8 19:02:48 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Mar 2015 18:02:48 +0000 Subject: Missmatch between web site version and install version. In-Reply-To: References: <78E7C1BB-2F2B-48D0-9FFF-BFA48321BE45@opencsw.org> Message-ID: 2015-03-05 1:41 GMT+00:00 Maciej (Matchek) Blizi?ski : > > 2015-03-04 9:21 GMT+00:00 Nils Ludvig Brandtz?g : > > I cannot see any updates in testing (munich) since 11-Dec-2014 > > (catalog/descriptions) and 25-Nov-2014 for packages > > (libstdc++6-4.9.2,REV=2014.11.07-SunOS5.10-sparc-CSW.pkg.gz etc). Me > > wrong? > > You're right, munich updates are broken: > > 2015/03/05 02:39:29 Problem in the catalog: Package CSWgit declares > dependency on CSWosshclient but CSWosshclient is missing from the > {munich sparc SunOS5.10} catalog. We have monitoring for the updates, but it has a flaw, and doesn't catch the breakage of munich. Updates run more or less like this: 10:00 OK unstable 10:10 OK unstable 10:20 FAILED unstable+munich 10:30 OK unstable 10:40 OK unstable If only the unstable+munich+others catalog generation fails, information about the failure is sent to Nagios. But 10 minutes later, an unstable generation starts and completes correctly, and the information about failed munich is lost, Nagios thinks that catalog generation works fine. To fix this, we need to split this into 2 separate probes / alerts. Could Dago or Jan look at this? Maciej From rmottola at opencsw.org Sun Mar 8 21:00:35 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 08 Mar 2015 21:00:35 +0100 Subject: missing libffi.so master link In-Reply-To: <54FC5704.8070806@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> Message-ID: <54FCAA63.8020801@opencsw.org> Hi, Laurent Blume wrote: > Le 2015/03/08 14:59 +0100, Dagobert Michelsen a ?crit: >> BUILD64 = 1 > Only this one is enough IMO. I falsely understood I could remove that. Since this is a library only, I think you are right. I get an error however when enabling BUILD64 This on unstable10x: libtool: link: /opt/csw/bin/gcc-4.9 -shared -fPIC -DPIC -Wl,-z -Wl,text -Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -O2 -m64 -march=opteron -m64 -march=opteron -m64 -march=opteron ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section type is SHT_PROGBITS: expected SHT_AMD64_UNWIND collect2: error: ld returned 1 exit status Makefile:1165: recipe for target 'libffi.la' failed however on unstable10s it works! http://buildfarm.opencsw.org/pkgdb/srv4/5a8ccc56778c96c5cba0d1876767ff92/ but I don't see differentiated 32bit and 64bit libraries, are you sure this is correct and I did not just a 64bit only On unstable9x: gmake[1]: Entering directory `/home/rmottola/opencsw/libffi/trunk' /home/rmottola/opencsw/.buildsys/v2/gar//gar.conf.mk:502: *** The ISA 'amd64' can not be build on this kernel with the arch 'i386'. Stop. gmake[1]: Leaving directory `/home/rmottola/opencsw/libffi/trunk' this is even worse, isn't 9x 64bit capable too?? perhaps 64BIT is not doing the correct thing. Unstable9s instead seems to work like unstable10s, that is a single package can't say if it is 32 and/or 64 bit http://buildfarm.opencsw.org/pkgdb/srv4/bd99bdeb7f90280e05a5e3640a4856b8/ that is, have trouble only on intel.. of which I don't know much. Help! Riccardo Riccardo From maciej at opencsw.org Sun Mar 8 21:12:16 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 8 Mar 2015 20:12:16 +0000 Subject: missing libffi.so master link In-Reply-To: <54FCAA63.8020801@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> Message-ID: 2015-03-08 20:00 GMT+00:00 Riccardo Mottola : > that is, have trouble only on intel.. of which I don't know much. Help! There is no 64-bit Intel Solaris 9. In the past we had packages which did the following: 1. Build 32-bit on Solaris 9 2. Build 64-bit on Solaris 10 Cheat and put 64-bit binaries, built on Solaris 10, into the Solaris 9 package. On Solaris 9 it was fine, because nothing tried to access them. On Solaris 10 it was fine, too, because both 32-bit and 64-bit binaries worked fine. I don't know if we ripped it out or not. I thought it would still work. The last time I did it, I just ran "mgar platforms" and it did the right thing. From laurent at opencsw.org Sun Mar 8 21:15:37 2015 From: laurent at opencsw.org (Laurent Blume) Date: Sun, 08 Mar 2015 21:15:37 +0100 Subject: missing libffi.so master link In-Reply-To: <54FCAA63.8020801@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> Message-ID: <54FCADE9.4010902@opencsw.org> Le 2015/03/08 21:00 +0100, Riccardo Mottola a ?crit: > This on unstable10x: > libtool: link: /opt/csw/bin/gcc-4.9 -shared -fPIC -DPIC -Wl,-z -Wl,text > -Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o > src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o > src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o > src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -O2 -m64 > -march=opteron -m64 -march=opteron -m64 -march=opteron > ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section > type is SHT_PROGBITS: expected SHT_AMD64_UNWIND > collect2: error: ld returned 1 exit status > Makefile:1165: recipe for target 'libffi.la' failed Some search seems to hint it's a GNU assembler / Solaris ld issue. There might be some optimization selected by ./configure that's not good. http://gcc.1065356.n5.nabble.com/Building-GCC-4-7-2-on-Solaris-10-x86-AMD64-Getting-linker-error-involving-eh-frame-td893484.html I see that option in configure that's probably worth enabling: --enable-portable-binary Check the config.log carefully. > that is, have trouble only on intel.. of which I don't know much. Help! Solaris 9 x86 is 32 bit only. My generic advice about it is: drop it. Laurent From rmottola at opencsw.org Mon Mar 9 08:42:47 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 09 Mar 2015 08:42:47 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> Message-ID: <54FD4EF7.5090900@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > I don't know if we ripped it out or not. I thought it would still > work. The last time I did it, I just ran "mgar platforms" and it did > the right thing. from which host do you run "mgar plaform" perhaps it has an order. Riccardo From rmottola at opencsw.org Mon Mar 9 08:59:53 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 09 Mar 2015 08:59:53 +0100 Subject: missing libffi.so master link In-Reply-To: <54FCADE9.4010902@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> <54FCADE9.4010902@opencsw.org> Message-ID: <54FD52F9.3010801@opencsw.org> Laurent Blume wrote: > Le 2015/03/08 21:00 +0100, Riccardo Mottola a ?crit: >> This on unstable10x: >> libtool: link: /opt/csw/bin/gcc-4.9 -shared -fPIC -DPIC -Wl,-z -Wl,text >> -Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o >> src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o >> src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o >> src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -O2 -m64 >> -march=opteron -m64 -march=opteron -m64 -march=opteron >> ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section >> type is SHT_PROGBITS: expected SHT_AMD64_UNWIND >> collect2: error: ld returned 1 exit status >> Makefile:1165: recipe for target 'libffi.la' failed > > Some search seems to hint it's a GNU assembler / Solaris ld issue. > There might be some optimization selected by ./configure that's not good. > http://gcc.1065356.n5.nabble.com/Building-GCC-4-7-2-on-Solaris-10-x86-AMD64-Getting-linker-error-involving-eh-frame-td893484.html > > > I see that option in configure that's probably worth enabling: > > --enable-portable-binary > > Check the config.log carefully. > I enabled that option. I don't seeit mentioned in the thread you cite though. I see this in the configure output. pentium-pro run: checking whether .eh_frame section should be read-only... expr: syntax error no amd64 run: checking toolchain supports unwind section type... no checking whether .eh_frame section should be read-only... expr: syntax error no and it could be related, it is the same section. The check before is about unwind, apparently run on amd64 only. in config.log I just see: configure:18550: checking toolchain supports unwind section type configure:18579: result: no configure:18589: checking whether .eh_frame section should be read-only configure:18609: result: no no trace of the "expr" error and of the actual test. >> that is, have trouble only on intel.. of which I don't know much. Help! > > Solaris 9 x86 is 32 bit only. My generic advice about it is: drop it. I'm fine for dropping x86, but I'd like tor retain solaris9 on sparc. May I or do I need to upload both packages together like it happens on solaris 10? seems like I became libffi maintainer :) Riccardo From dam at opencsw.org Mon Mar 9 09:08:43 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Mon, 9 Mar 2015 09:08:43 +0100 Subject: missing libffi.so master link In-Reply-To: <54FD52F9.3010801@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> <54FCADE9.4010902@opencsw.org> <54FD52F9.3010801@opencsw.org> Message-ID: <355F8E3E-1E5C-44AF-94C1-7C57F17A2499@opencsw.org> Hi Riccardo, > Am 09.03.2015 um 08:59 schrieb Riccardo Mottola : > > Laurent Blume wrote: >> Le 2015/03/08 21:00 +0100, Riccardo Mottola a ?crit: >>> This on unstable10x: >>> libtool: link: /opt/csw/bin/gcc-4.9 -shared -fPIC -DPIC -Wl,-z -Wl,text >>> -Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o >>> src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o >>> src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o >>> src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -O2 -m64 >>> -march=opteron -m64 -march=opteron -m64 -march=opteron >>> ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section >>> type is SHT_PROGBITS: expected SHT_AMD64_UNWIND >>> collect2: error: ld returned 1 exit status >>> Makefile:1165: recipe for target 'libffi.la' failed >> >> Some search seems to hint it's a GNU assembler / Solaris ld issue. There might be some optimization selected by ./configure that's not good. >> http://gcc.1065356.n5.nabble.com/Building-GCC-4-7-2-on-Solaris-10-x86-AMD64-Getting-linker-error-involving-eh-frame-td893484.html >> >> I see that option in configure that's probably worth enabling: >> >> --enable-portable-binary >> >> Check the config.log carefully. >> > I enabled that option. I don't seeit mentioned in the thread you cite though. > > I see this in the configure output. > > pentium-pro run: > checking whether .eh_frame section should be read-only... expr: syntax error > no > > amd64 run: > checking toolchain supports unwind section type... no > checking whether .eh_frame section should be read-only... expr: syntax error > no > > and it could be related, it is the same section. The check before is about unwind, apparently run on amd64 only. > > in config.log I just see: > configure:18550: checking toolchain supports unwind section type > configure:18579: result: no > configure:18589: checking whether .eh_frame section should be read-only > configure:18609: result: no > > no trace of the "expr" error and of the actual test. Take a look in config.log, if in doubt add ?set -e? to configure and store the output. >>> that is, have trouble only on intel.. of which I don't know much. Help! >> >> Solaris 9 x86 is 32 bit only. My generic advice about it is: drop it. > > I'm fine for dropping x86, but I'd like tor retain solaris9 on sparc. May I or do I need to upload both packages together like it happens on solaris 10? Please *always* provide x86 and sparc. Rule of thumb: dropping something altogether is better than providing for one ISA only. > seems like I became libffi maintainer :) Welcome to the club :) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Mon Mar 9 20:52:16 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 09 Mar 2015 20:52:16 +0100 Subject: missing libffi.so master link In-Reply-To: <355F8E3E-1E5C-44AF-94C1-7C57F17A2499@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> <54FCADE9.4010902@opencsw.org> <54FD52F9.3010801@opencsw.org> <355F8E3E-1E5C-44AF-94C1-7C57F17A2499@opencsw.org> Message-ID: <54FDF9F0.2000408@opencsw.org> Hi Dago, Dagobert Michelsen wrote: >> in config.log I just see: >> configure:18550: checking toolchain supports unwind section type >> configure:18579: result: no >> configure:18589: checking whether .eh_frame section should be read-only >> configure:18609: result: no >> >> no trace of the "expr" error and of the actual test. > Take a look in config.log, if in doubt add ?set -e? to configure and store the output. I pasted the excerpt of config.log above. I added set -e (It took me some time to understand I had to add it to the script itself). I attach it here together with the config.log, see if you get smart out of it! I don't. >>>> I'm fine for dropping x86, but I'd like tor retain solaris9 on sparc. May I or do I need to upload both packages together like it happens on solaris 10? I don't know, I may dissent, I think SPARC has a longer lifespan because of the hardware. I still have a solaris 8 box, I know of several hobbyst who do, however intel stuff is always fresh and up to date. But well of course I hope to get everything working again, maybe Maciej's trick will do. Riccardo -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.Z Type: application/x-compress Size: 24004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: confout.Z Type: application/x-compress Size: 5889 bytes Desc: not available URL: From rmottola at opencsw.org Thu Mar 12 14:28:53 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 12 Mar 2015 14:28:53 +0100 Subject: missing libffi.so master link In-Reply-To: <54FDF9F0.2000408@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> <54FCADE9.4010902@opencsw.org> <54FD52F9.3010801@opencsw.org> <355F8E3E-1E5C-44AF-94C1-7C57F17A2499@opencsw.org> <54FDF9F0.2000408@opencsw.org> Message-ID: <55019495.9070705@opencsw.org> Hi, Riccardo Mottola wrote: > Hi Dago, > > Dagobert Michelsen wrote: >>> in config.log I just see: >>> configure:18550: checking toolchain supports unwind section type >>> configure:18579: result: no >>> configure:18589: checking whether .eh_frame section should be read-only >>> configure:18609: result: no >>> >>> no trace of the "expr" error and of the actual test. >> Take a look in config.log, if in doubt add ?set -e? to configure and >> store the output. > I pasted the excerpt of config.log above. > > I added set -e (It took me some time to understand I had to add it to > the script itself). > > I attach it here together with the config.log, see if you get smart > out of it! I don't anybody has a better clue about these two configure checks? I think they might be the culprit for the amd64 failure. I don't... I see nothing in the logs that helps. I fear "expr" could be a problem that a test is run with a non-GNU tool and it fails, but about unwind... I don't know and it could be the problem. Riccardo From dam at opencsw.org Thu Mar 12 15:00:34 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Thu, 12 Mar 2015 15:00:34 +0100 Subject: missing libffi.so master link In-Reply-To: <55019495.9070705@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> <54FCADE9.4010902@opencsw.org> <54FD52F9.3010801@opencsw.org> <355F8E3E-1E5C-44AF-94C1-7C57F17A2499@opencsw.org> <54FDF9F0.2000408@opencsw.org> <55019495.9070705@opencsw.org> Message-ID: Hi Riccardo, > Am 12.03.2015 um 14:28 schrieb Riccardo Mottola : > > Riccardo Mottola wrote: >> Hi Dago, >> >> Dagobert Michelsen wrote: >>>> in config.log I just see: >>>> configure:18550: checking toolchain supports unwind section type >>>> configure:18579: result: no >>>> configure:18589: checking whether .eh_frame section should be read-only >>>> configure:18609: result: no >>>> >>>> no trace of the "expr" error and of the actual test. >>> Take a look in config.log, if in doubt add ?set -e? to configure and >>> store the output. >> I pasted the excerpt of config.log above. >> >> I added set -e (It took me some time to understand I had to add it to >> the script itself). You must add it to the top of ?configure?. >> I attach it here together with the config.log, see if you get smart >> out of it! I don't > > anybody has a better clue about these two configure checks? I think they might be the culprit for the amd64 failure. I don't... I see nothing in the logs that helps. > > I fear "expr" could be a problem that a test is run with a non-GNU tool and it fails, but about unwind... I don't know and it could be the problem. Look here: > configure:6217: checking for objdump > configure:6247: result: no The missing check for the non-availability of objdump leads to the output being empty and finally to ?expr + 1? which is invalid: > + printf '%s\n' 'configure:18591: checking whether .eh_frame section should be read-only' > + printf %s 'checking whether .eh_frame section should be read-only... ' > checking whether .eh_frame section should be read-only... + false > + libffi_cv_ro_eh_frame=no > + echo 'extern void foo (void); void bar (void) { foo (); foo (); }' > + /opt/csw/bin/gcc-4.9 -O2 -pipe -m64 -march=opteron -Wall -fexceptions -c -fpic -fexceptions -o conftest.o conftest.c > + objdump -h conftest.o > ++ grep -n eh_frame conftest.dump > ++ cut -d: -f 1 > + libffi_eh_frame_line= > ++ expr + 1 > expr: syntax error > + libffi_test_line=p > + sed -n p conftest.dump > + grep READONLY conftest.line > + rm -f conftest.c conftest.dump conftest.line conftest.o > + printf '%s\n' 'configure:18611: result: no' > + printf '%s\n' no > no I committed an adjusted PATH during configure in r24719. However, the compilation still fails with > libtool: link: /opt/csw/bin/gcc-4.9 -shared -fPIC -DPIC -Wl,-z -Wl,text -Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -O2 -m64 -march=opteron -m64 -march=opteron -m64 -march=opteron > ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section type is SHT_PROGBITS: expected SHT_AMD64_UNWIND > collect2: error: ld returned 1 exit status Probably you need to dive deeper in ELF and linking. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Fri Mar 13 10:22:15 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 13 Mar 2015 10:22:15 +0100 Subject: linker eh_frame unwind [was: missing libffi.so master link] In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> <54FCADE9.4010902@opencsw.org> <54FD52F9.3010801@opencsw.org> <355F8E3E-1E5C-44AF-94C1-7C57F17A2499@opencsw.org> <54FDF9F0.2000408@opencsw.org> <55019495.9070705@opencsw.org> Message-ID: <5502AC47.6080008@opencsw.org> Hi, thank you, Dago. I made some important discovery, more below. I think a test failing is the problem. Dagobert Michelsen wrote: > I committed an adjusted PATH during configure in r24719. However, the compilation > still fails with > >> >libtool: link:/opt/csw/bin/gcc-4.9 -shared -fPIC -DPIC -Wl,-z -Wl,text -Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64 -O2 -m64 -march=opteron -m64 -march=opteron -m64 -march=opteron >> >ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section type is SHT_PROGBITS: expected SHT_AMD64_UNWIND >> >collect2: error: ld returned 1 exit status > Probably you need to dive deeper in ELF and linking. I think the problem is that the test: checking toolchain supports unwind section type... no returns no and not yes. In fact, we have this in the code: #ifdef __GNUC__ /* Only emit DWARF unwind info when building with the GNU toolchain. */ #ifdef HAVE_AS_X86_64_UNWIND_SECTION_TYPE .section .eh_frame,"a", at unwind #else .section .eh_frame,"a", at progbits #endif (only for GNUC, this is why this wasn't happening with previous suncc, I don't know why it does work on 32bit though). I manually defined in i386-pc-solaris2.10/fficonfig.h HAVE_AS_X86_64_UNWIND_SECTION_TYPE to 1 An now build completes. Which makes sense: it is exactly the warning our linker is spitting out. The question is now: why does the check fail? I did some search and found this: https://github.com/atgreen/libffi/issues/42 "Ensure the whole toolchain supports unwind section type" For your convenience, a quick link to the patch: https://hg.mozilla.org/mozilla-central/diff/94dc6f0b5f8b/js/src/ctypes/libffi/configure.ac The goal would be that both compiler and linker support the type. We should have this patch (our message says "toolchain") Why does it fail? the check should return "yes", the test explicitly says linker. Could it be that a different linker is used? That our environment is not set up correctly? Linking is done with $CC, so it should be fine, shouldn't it? Riccardo From laurent at opencsw.org Fri Mar 13 10:25:21 2015 From: laurent at opencsw.org (Laurent Blume) Date: Fri, 13 Mar 2015 10:25:21 +0100 Subject: linker eh_frame unwind [was: missing libffi.so master link] In-Reply-To: <5502AC47.6080008@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <54FC4E2D.4090903@opencsw.org> <54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org> <54FCADE9.4010902@opencsw.org> <54FD52F9.3010801@opencsw.org> <355F8E3E-1E5C-44AF-94C1-7C57F17A2499@opencsw.org> <54FDF9F0.2000408@opencsw.org> <55019495.9070705@opencsw.org> <5502AC47.6080008@opencsw.org> Message-ID: <5502AD01.5050104@opencsw.org> Le 2015/03/13 10:22 +0100, Riccardo Mottola a ?crit: > Why does it fail? the check should return "yes", Well, what is the test? From rmottola at opencsw.org Fri Mar 13 17:16:05 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 13 Mar 2015 17:16:05 +0100 Subject: libffi unwind test fails Message-ID: <55030D44.7020604@opencsw.org> Hi, the other thread reached a too deep reply level and got a bit out of topic :) The summary is: the toolchain supports unwind section type returns no even if it should return yes. This makes solaris-x86-64 fail. The test is executed only if target is X86_64, this is why we weren't seeing the test in the 32bit build. The full test check in configure.ac is: if test x$TARGET = xX86_64; then AC_CACHE_CHECK([toolchain supports unwind section type], libffi_cv_as_x86_64_unwind_section_type, [ cat > conftest1.s << EOF .text .globl foo foo: jmp bar .section .eh_frame,"a", at unwind bar: EOF cat > conftest2.c << EOF extern void foo(); int main(){foo();} EOF libffi_cv_as_x86_64_unwind_section_type=no # we ensure that we can compile _and_ link an assembly file containing an @unwind section # since the compiler can support it and not the linker (ie old binutils) if $CC -Wa,--fatal-warnings $CFLAGS -c conftest1.s > /dev/null 2>&1 && \ $CC conftest2.c conftest1.o > /dev/null 2>&1 ; then libffi_cv_as_x86_64_unwind_section_type=yes fi ]) if test "x$libffi_cv_as_x86_64_unwind_section_type" = xyes; then AC_DEFINE(HAVE_AS_X86_64_UNWIND_SECTION_TYPE, 1, [Define if your assembler supports unwind section type.]) fi fi it links with $CC a small piece with assembler and tries to see if there are warnings. I created the two files manually, I tried: gcc -Wa,--fatal-warnings -m64 -c conftest1.s and got no error. (without -m64, I would get an unrecognized section type) then I do: cc -m64 conftest2.c conftest1.o and get no errors, so the test should pass. What's wrong? Riccardo From laurent at opencsw.org Sun Mar 15 15:58:42 2015 From: laurent at opencsw.org (Laurent Blume) Date: Sun, 15 Mar 2015 15:58:42 +0100 Subject: libffi unwind test fails In-Reply-To: <55030D44.7020604@opencsw.org> References: <55030D44.7020604@opencsw.org> Message-ID: <55059E22.4020009@opencsw.org> Look closer at the lines you've just quoted: if $CC -Wa,--fatal-warnings $CFLAGS -c conftest1.s > /dev/null 2>&1 && \ $CC conftest2.c conftest1.o > /dev/null 2>&1 ; then See the $CFLAGS for the first GCC call? It's missing for the second. So you get that actually executed: + gcc -Wa,--fatal-warnings -m64 -Wall -fexceptions -c conftest1.s + gcc conftest2.c conftest1.o The first succeeds, creates a 64 bit object. The second fails, because it tries to link a 64 bit object in 32 bit mode (the default). Add a $CFLAGS, it'll work better. Report upstream too. Laurent On 13/03/2015 17:16, Riccardo Mottola wrote: > Hi, > > the other thread reached a too deep reply level and got a bit out of > topic :) The summary is: the toolchain supports unwind section type > returns no even if it should return yes. This makes solaris-x86-64 fail. > The test is executed only if target is X86_64, this is why we weren't > seeing the test in the 32bit build. > > The full test check in configure.ac is: > if test x$TARGET = xX86_64; then > AC_CACHE_CHECK([toolchain supports unwind section type], > libffi_cv_as_x86_64_unwind_section_type, [ > cat > conftest1.s << EOF > .text > .globl foo > foo: > jmp bar > .section .eh_frame,"a", at unwind > bar: > EOF > > cat > conftest2.c << EOF > extern void foo(); > int main(){foo();} > EOF > > libffi_cv_as_x86_64_unwind_section_type=no > # we ensure that we can compile _and_ link an assembly file > containing an @unwind section > # since the compiler can support it and not the linker (ie old > binutils) > if $CC -Wa,--fatal-warnings $CFLAGS -c conftest1.s > /dev/null > 2>&1 && \ > $CC conftest2.c conftest1.o > /dev/null 2>&1 ; then > libffi_cv_as_x86_64_unwind_section_type=yes > fi > ]) > if test "x$libffi_cv_as_x86_64_unwind_section_type" = xyes; then > AC_DEFINE(HAVE_AS_X86_64_UNWIND_SECTION_TYPE, 1, > [Define if your assembler supports unwind section > type.]) > fi > fi > > it links with $CC a small piece with assembler and tries to see if there > are warnings. > > I created the two files manually, I tried: > gcc -Wa,--fatal-warnings -m64 -c conftest1.s > > and got no error. (without -m64, I would get an unrecognized section type) > > then I do: > cc -m64 conftest2.c conftest1.o > > > and get no errors, so the test should pass. > > What's wrong? > > Riccardo > From rmottola at opencsw.org Sun Mar 15 23:49:27 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 15 Mar 2015 23:49:27 +0100 Subject: libffi unwind test fails In-Reply-To: <55059E22.4020009@opencsw.org> References: <55030D44.7020604@opencsw.org> <55059E22.4020009@opencsw.org> Message-ID: <55060C77.9080605@opencsw.org> Hi Laurent, Laurent Blume wrote: > So you get that actually executed: > + gcc -Wa,--fatal-warnings -m64 -Wall -fexceptions -c conftest1.s > + gcc conftest2.c conftest1.o > > The first succeeds, creates a 64 bit object. The second fails, because > it tries to link a 64 bit object in 32 bit mode (the default). > > Add a $CFLAGS, it'll work better. Report upstream too. keen eyes! that was it. When I executed the test manually, I instictively added -m64 and thus it workd for me! Patched, built and commited. The brand new packages are uploaded. "mgar platforms" packaged solaris 9 x86 fine too. I also sent the bug upstream with the patch, hopefully they merge it in. Riccardo From rmottola at opencsw.org Mon Mar 16 22:05:53 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 16 Mar 2015 22:05:53 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> Message-ID: <550745B1.903@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > 2015-03-08 11:31 GMT+00:00 Laurent Blume : >> I've not looked much into it, Just noticed that the .so of that libffi >> is in a different subdir. I see no .so for the GCC one, nor dependency >> on it, so it looks basically useless. > Yes, it is useless now. This quirk comes from the times when we > couldn't, or didn't want to remove gcc3 from the catalog. Riccardo, > I'd suggest moving the .so file back to /opt/csw/lib. The odyssey is not done! we have a clash: INFO 2015-03-16 21:54:56,221 package_stats.py:132 Juicing the svr4 package stream files... 100% Time: 0:00:23 |#############################################################################| INFO 2015-03-16 21:55:22,464 checkpkg_lib.py:263 Unwrapping candies... 100% |###########################################################################################| INFO 2015-03-16 21:55:22,521 checkpkg_lib.py:878 Tasting candies one by one... 100% |###########################################################################################| INFO 2015-03-16 21:55:23,206 checkpkg_lib.py:914 Tasting them all at once... INFO 2015-03-16 21:55:31,725 checkpkg_lib.py:305 Stuffing the candies under the pillow... WARNING 2015-03-16 21:55:31,825 checkpkg_lib.py:311 Not saving an error for CSWgcc3javart. | WARNING 2015-03-16 21:55:31,826 checkpkg_lib.py:311 Not saving an error for CSWgcc3javart. WARNING 2015-03-16 21:55:31,827 checkpkg_lib.py:311 Not saving an error for CSWgcc4core. | WARNING 2015-03-16 21:55:31,828 checkpkg_lib.py:311 Not saving an error for CSWgcc4core. 100% |###########################################################################################| CSWlibffi-dev: CSWgcc3javart: CSWgcc4core: If any of the reported errors were false positives, you can override them pasting the lines below to the GAR recipe. CHECKPKG_OVERRIDES_CSWlibffi-dev += file-collision|/opt/csw/lib/libffi.so|CSWgcc3javart|CSWgcc4core|CSWlibffi-dev CHECKPKG_OVERRIDES_CSWlibffi-dev += file-collision|/opt/csw/lib/sparcv9/libffi.so|CSWgcc3javart|CSWgcc4core|CSWlibffi-dev is this CSWgcc3javart package still actual? Why does it want a private libffi version? I think that was probabl the package that was the reason for this "hiding" of libffi.so What now, should I revert my changes in libffi or can we clean up this stubborn package or at least update it to use a system libffi? Riccardo From rmottola at opencsw.org Mon Mar 16 22:06:04 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 16 Mar 2015 22:06:04 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> Message-ID: <550745BC.2020306@opencsw.org> Hi Maciej Maciej (Matchek) Blizi?ski wrote: > Yes, it is useless now. This quirk comes from the times when we > couldn't, or didn't want to remove gcc3 from the catalog. Riccardo, > I'd suggest moving the .so file back to /opt/csw/lib. the packages I uploaded yesterday did build & link fine finally! however I forgot that detail. I think the fix was easy, I removed one explicit remove & link line and changed the install targets. Looks fine. Uploading son. I hope this is the final one finally! Riccardo From maciej at opencsw.org Tue Mar 17 01:25:51 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 17 Mar 2015 00:25:51 +0000 Subject: missing libffi.so master link In-Reply-To: <550745B1.903@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> Message-ID: 2015-03-16 21:05 GMT+00:00 Riccardo Mottola : > is this CSWgcc3javart package still actual? Why does it want a private > libffi version? I think that was probabl the package that was the reason > for this "hiding" of libffi.so > Quick check, CSWgcc3javart only exists in the Solaris 9 unstable catalog. curl -s https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/catalog | grep CSWgcc3javart We could drop CSWgcc3java from the unstable Solaris 9 catalog. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurent at opencsw.org Tue Mar 17 10:09:50 2015 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 17 Mar 2015 10:09:50 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> Message-ID: <5507EF5E.1030609@opencsw.org> Le 2015/03/17 01:25 +0100, Matchek a ?crit: > Quick check, CSWgcc3javart only exists in the Solaris 9 unstable catalog. > > curl -s https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/catalog | > grep CSWgcc3javart > > We could drop CSWgcc3java from the unstable Solaris 9 catalog. Agreed. AFAIR, it was not a very useful Java implementation. Laurent From rmottola at opencsw.org Tue Mar 17 10:41:33 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 17 Mar 2015 10:41:33 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> Message-ID: <5507F6CD.4020006@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > Quick check, CSWgcc3javart only exists in the Solaris 9 unstable catalog. > > curl -s https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/catalog > | grep CSWgcc3javart > > We could drop CSWgcc3java from the unstable Solaris 9 catalog. Is there something dependent on it? we have gcc4java in the solaris catalog. In case cc java needed, isn't it better to use the gcc 4 version anyway? I'm for removing it, there is a newer replacement. Riccardo From dam at opencsw.org Tue Mar 17 10:46:54 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Mar 2015 10:46:54 +0100 Subject: missing libffi.so master link In-Reply-To: <5507F6CD.4020006@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> Message-ID: <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> Hi Riccardo, > Am 17.03.2015 um 10:41 schrieb Riccardo Mottola : > > Maciej (Matchek) Blizi?ski wrote: >> Quick check, CSWgcc3javart only exists in the Solaris 9 unstable catalog. >> >> curl -s https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/catalog | grep CSWgcc3javart >> >> We could drop CSWgcc3java from the unstable Solaris 9 catalog. > > Is there something dependent on it? we have gcc4java in the solaris catalog. In case cc java needed, isn't it better to use the gcc 4 version anyway? > I'm for removing it, there is a newer replacement. ?which is also broken: https://www.opencsw.org/mantis/view.php?id=5045 I would love to see that fixed for pdftk which requires gcj, but this looks harder to fix. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Tue Mar 17 12:18:51 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 17 Mar 2015 12:18:51 +0100 Subject: missing libffi.so master link In-Reply-To: <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> Message-ID: <55080D9B.5040307@opencsw.org> Hi, Dagobert Michelsen wrote: > Hi Riccardo, > >> Am 17.03.2015 um 10:41 schrieb Riccardo Mottola : >> >> Maciej (Matchek) Blizi?ski wrote: >>> Quick check, CSWgcc3javart only exists in the Solaris 9 unstable catalog. >>> >>> curl -s https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/catalog | grep CSWgcc3javart >>> >>> We could drop CSWgcc3java from the unstable Solaris 9 catalog. >> Is there something dependent on it? we have gcc4java in the solaris catalog. In case cc java needed, isn't it better to use the gcc 4 version anyway? >> I'm for removing it, there is a newer replacement. > ?which is also broken: > https://www.opencsw.org/mantis/view.php?id=5045 > > I would love to see that fixed for pdftk which requires gcj, but this looks > harder to fix. > and gcc3 java did work? but it is in solaris 9 anyway, so pdftk on solaris 10 where you have gcc4 now? I understand that to get pdftk to work on sol.10 you need a working gcj4 anyway, so it doesn't speak against removing this. Riccardo From rmottola at opencsw.org Tue Mar 17 12:21:53 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 17 Mar 2015 12:21:53 +0100 Subject: patching a specific solaris version Message-ID: <55080E51.7070006@opencsw.org> Hi, I don't remember if I asked this: but suppose I need a patch to get solaris9 working but not solaris 10. May I mark a patch to be applied only for it in mgar? that means the patch is easier to write (no strange ifdefs). The same question for x86 vs sparc. Riccardo From grzemba at contac-dt.de Tue Mar 17 12:57:24 2015 From: grzemba at contac-dt.de (Carsten Grzemba) Date: Tue, 17 Mar 2015 12:57:24 +0100 Subject: patching a specific solaris version In-Reply-To: References: <55080E51.7070006@opencsw.org> Message-ID: Such things I have done here: e.g. for GARCOMPILER or GARCH in PATCH_FILES and RUNTIME_DEP_PKGS https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/389-ds-base/branches/vers1.3.2/Makefile Am 17.03.15 schrieb Riccardo Mottola : > Hi, > > I don't remember if I asked this: but suppose I need a patch to get solaris9 working but not solaris 10. May I mark a patch to be applied only for it in mgar? that means the patch is easier to write (no strange ifdefs). > > The same question for x86 vs sparc. > > Riccardo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dam at opencsw.org Tue Mar 17 13:33:19 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 17 Mar 2015 13:33:19 +0100 Subject: missing libffi.so master link In-Reply-To: <55080D9B.5040307@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> Message-ID: <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> Hi Riccardo, > Am 17.03.2015 um 12:18 schrieb Riccardo Mottola : > > Dagobert Michelsen wrote: >>> Am 17.03.2015 um 10:41 schrieb Riccardo Mottola : >>> Maciej (Matchek) Blizi?ski wrote: >>>> Quick check, CSWgcc3javart only exists in the Solaris 9 unstable catalog. >>>> >>>> curl -s https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/catalog | grep CSWgcc3javart >>>> >>>> We could drop CSWgcc3java from the unstable Solaris 9 catalog. >>> Is there something dependent on it? we have gcc4java in the solaris catalog. In case cc java needed, isn't it better to use the gcc 4 version anyway? >>> I'm for removing it, there is a newer replacement. >> >> ?which is also broken: >> https://www.opencsw.org/mantis/view.php?id=5045 >> >> I would love to see that fixed for pdftk which requires gcj, but this looks >> harder to fix. > > and gcc3 java did work? I don?t know, probably not. > but it is in solaris 9 anyway, so pdftk on solaris 10 where you have gcc4 now? > I understand that to get pdftk to work on sol.10 you need a working gcj4 anyway, so it doesn't speak against removing this. I did not intend it as arguments against removing gcc3java, more like in favor of also removing gcc4java :-) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Wed Mar 18 08:51:53 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 18 Mar 2015 08:51:53 +0100 Subject: patching a specific solaris version In-Reply-To: References: <55080E51.7070006@opencsw.org> Message-ID: <55092E99.1040202@opencsw.org> Hi Carsten Grzemba wrote: > Such things I have done here: > > e.g. for GARCOMPILER or GARCH in PATCH_FILES and RUNTIME_DEP_PKGS > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/389-ds-base/branches/vers1.3.2/Makefile Interesting. What are the GARCH values? sparc and x86? How do I access solaris9 vs solaris10 instead? The value of the current packaging platform would be good. Riccardo From rmottola at opencsw.org Wed Mar 18 08:52:31 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 18 Mar 2015 08:52:31 +0100 Subject: missing libffi.so master link In-Reply-To: <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> Message-ID: <55092EBF.7010502@opencsw.org> Hi, Dagobert Michelsen wrote: > I don?t know, probably not. > have you actually tried more current stuff, your bug is from gcc 4.7 >> >but it is in solaris 9 anyway, so pdftk on solaris 10 where you have gcc4 now? >> >I understand that to get pdftk to work on sol.10 you need a working gcj4 anyway, so it doesn't speak against removing this. > I did not intend it as arguments against removing gcc3java, more like in favor > of also removing gcc4java:-) if somebody finalizes the removal of gcc3java, I will try to build libffi once again! Riccardo From rmottola at opencsw.org Wed Mar 18 08:55:11 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 18 Mar 2015 08:55:11 +0100 Subject: gcc receipe and architecture comment Message-ID: <55092F5F.6010007@opencsw.org> Hi, in the gcc receipe, which would be the last version that is supposed to run on solaris 9, I find this: # We're not building GCC-4.7 on Solaris 9, because GCC-4.7 requires the # sparcv8+ architecture. # PACKAGING_PLATFORMS = solaris9-sparc solaris9-i386 PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 Why is v8+ a problem? I understand we support UltraSPARC only anyway, be it 32 or 64 bit. I actually think to remember that the last operating system running on the "classic" SPARCs, is Solaris 8. I wanted to upgrade gcc there. Riccardo From dam at opencsw.org Wed Mar 18 09:26:53 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Mar 2015 09:26:53 +0100 Subject: patching a specific solaris version In-Reply-To: <55092E99.1040202@opencsw.org> References: <55080E51.7070006@opencsw.org> <55092E99.1040202@opencsw.org> Message-ID: Hi Riccardo, > Am 18.03.2015 um 08:51 schrieb Riccardo Mottola : > > Carsten Grzemba wrote: >> Such things I have done here: >> >> e.g. for GARCOMPILER or GARCH in PATCH_FILES and RUNTIME_DEP_PKGS >> https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/389-ds-base/branches/vers1.3.2/Makefile > > Interesting. What are the GARCH values? sparc and x86? That is sparc and i386 as returned from ?uname -p?: https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/gar/v2/gar.conf.mk#85 > How do I access solaris9 vs solaris10 instead? That would be GAROSREL which is 5.9, 5.10 and 5.11. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Wed Mar 18 09:41:00 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Mar 2015 09:41:00 +0100 Subject: missing libffi.so master link In-Reply-To: <55092EBF.7010502@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> <55092EBF.7010502@opencsw.org> Message-ID: <4A24FD39-9CA3-4251-AF9C-FD8CDD12A685@opencsw.org> Hi Riccardo, > Am 18.03.2015 um 08:52 schrieb Riccardo Mottola : > > Dagobert Michelsen wrote: >> I don?t know, probably not. > > have you actually tried more current stuff, your bug is from gcc 4.7 Yes, I try every new gcc version I build and the error is still the same. I am afraid it needs to be analyzed and won?t go away automtatically. > if somebody finalizes the removal of gcc3java, I will try to build libffi once again! I just took another look and the error message is > CHECKPKG_OVERRIDES_CSWlibffi-dev += file-collision|/opt/csw/lib/libffi.so|CSWgcc3javart|CSWgcc4core|CSWlibffi-dev > CHECKPKG_OVERRIDES_CSWlibffi-dev += file-collision|/opt/csw/lib/sparcv9/libffi.so|CSWgcc3javart|CSWgcc4core|CSWlibffi-dev and yes, the symlink is also in gcc4core and the link is there on unstable9s: > /opt/csw/lib/libffi.so=libffi.so.4.0.1 s none CSWgcc4core Of course I can remove gcc3java, but we also need to take care of gcc4java. @Maciej: I guess I need to rebuild gcc for this, right? 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Wed Mar 18 10:06:07 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Mar 2015 10:06:07 +0100 Subject: gcc receipe and architecture comment In-Reply-To: <55092F5F.6010007@opencsw.org> References: <55092F5F.6010007@opencsw.org> Message-ID: Hi Riccardo, > Am 18.03.2015 um 08:55 schrieb Riccardo Mottola : > > in the gcc receipe, which would be the last version that is supposed to run on solaris 9, I find this: > > # We're not building GCC-4.7 on Solaris 9, because GCC-4.7 requires the > # sparcv8+ architecture. > # PACKAGING_PLATFORMS = solaris9-sparc solaris9-i386 > PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 > > Why is v8+ a problem? I understand we support UltraSPARC only anyway, be it 32 or 64 bit. > I actually think to remember that the last operating system running on the "classic" SPARCs, is Solaris 8. Nope, the minimum CPU level for Solaris 9 was sparcv8 whereas gcc 4.7 required sparcv8+ That does not mean you couldn?t just build with sparcv8+ and release for Solaris 9 as it would work on any platform past stonehenge. > I wanted to upgrade gcc there. I am impressed by the level of your pain endurance. Bets 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Wed Mar 18 10:29:34 2015 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Wed, 18 Mar 2015 09:29:34 +0000 Subject: gcc receipe and architecture comment In-Reply-To: References: <55092F5F.6010007@opencsw.org> Message-ID: <20150318092934.GA4152@quince> On Wed, Mar 18, 2015 at 10:06:07AM +0100, Dagobert Michelsen wrote: > Hi Riccardo, > > > Am 18.03.2015 um 08:55 schrieb Riccardo Mottola : > > > > in the gcc receipe, which would be the last version that is supposed to run on solaris 9, I find this: > > > > # We're not building GCC-4.7 on Solaris 9, because GCC-4.7 requires the > > # sparcv8+ architecture. > > # PACKAGING_PLATFORMS = solaris9-sparc solaris9-i386 > > PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 > > > > Why is v8+ a problem? I understand we support UltraSPARC only anyway, be it 32 or 64 bit. > > I actually think to remember that the last operating system running on the "classic" SPARCs, is Solaris 8. > > Nope, the minimum CPU level for Solaris 9 was sparcv8 whereas gcc 4.7 required sparcv8+ > That does not mean you couldn?t just build with sparcv8+ and release for Solaris 9 as > it would work on any platform past stonehenge. Right, it was the default setting in GAR for 5.9: to build sparcv8 binaries. There was a time your packages would be rejected if you built binaries for sparcv8+. This policy is now gone, and you can build and release sparcv8+ binaries. We had a similar rule to build for 386, where 386 didn't stand for just Intel processors, it actually meant the 386 processor, as opposed to the newer 486. Maciej From dam at opencsw.org Wed Mar 18 10:39:23 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Wed, 18 Mar 2015 10:39:23 +0100 Subject: gcc receipe and architecture comment In-Reply-To: <20150318092934.GA4152@quince> References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> Message-ID: Hi, > Am 18.03.2015 um 10:29 schrieb Maciej Blizi?ski : > > On Wed, Mar 18, 2015 at 10:06:07AM +0100, Dagobert Michelsen wrote: >>> Am 18.03.2015 um 08:55 schrieb Riccardo Mottola : >>> >>> in the gcc receipe, which would be the last version that is supposed to run on solaris 9, I find this: >>> >>> # We're not building GCC-4.7 on Solaris 9, because GCC-4.7 requires the >>> # sparcv8+ architecture. >>> # PACKAGING_PLATFORMS = solaris9-sparc solaris9-i386 >>> PACKAGING_PLATFORMS += solaris10-sparc solaris10-i386 >>> >>> Why is v8+ a problem? I understand we support UltraSPARC only anyway, be it 32 or 64 bit. >>> I actually think to remember that the last operating system running on the "classic" SPARCs, is Solaris 8. >> >> Nope, the minimum CPU level for Solaris 9 was sparcv8 whereas gcc 4.7 required sparcv8+ >> That does not mean you couldn?t just build with sparcv8+ and release for Solaris 9 as >> it would work on any platform past stonehenge. > > Right, it was the default setting in GAR for 5.9: to build sparcv8 > binaries. There was a time your packages would be rejected if you built > binaries for sparcv8+. This policy is now gone, and you can build and > release sparcv8+ binaries. > > We had a similar rule to build for 386, where 386 didn't stand for just > Intel processors, it actually meant the 386 processor, as opposed to the > newer 486. I just looked and we raised the automatic buildlevel for Solaris 10 only: https://buildfarm.opencsw.org/trac/changeset/15907 If you build gcc for Solaris 9 you need to manually raise the buildlevel. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Wed Mar 18 10:49:58 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 18 Mar 2015 09:49:58 +0000 Subject: gcc receipe and architecture comment In-Reply-To: References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> Message-ID: 2015-03-18 9:39 GMT+00:00 Dagobert Michelsen : > I just looked and we raised the automatic buildlevel for Solaris 10 only: > https://buildfarm.opencsw.org/trac/changeset/15907 > > If you build gcc for Solaris 9 you need to manually raise the buildlevel. Why don't we do it for Solaris 9 too? (Will require a checkpkg code update too. We are checking for this policy.) One concern could be that we don't want to screw up the Solaris 9 catalog: if we were to freeze it as is, in an old but otherwise good state, it's better than screwing it up and leaving it in an bad state. Rebuilding GCC should not cause that. Maciej From maciej at opencsw.org Wed Mar 18 11:02:23 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 18 Mar 2015 10:02:23 +0000 Subject: missing libffi.so master link In-Reply-To: <4A24FD39-9CA3-4251-AF9C-FD8CDD12A685@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> <55092EBF.7010502@opencsw.org> <4A24FD39-9CA3-4251-AF9C-FD8CDD12A685@opencsw.org> Message-ID: 2015-03-18 8:41 GMT+00:00 Dagobert Michelsen : > and yes, the symlink is also in gcc4core and the link is there on unstable9s: > >> /opt/csw/lib/libffi.so=libffi.so.4.0.1 s none CSWgcc4core > > Of course I can remove gcc3java, but we also need to take care of gcc4java. > @Maciej: I guess I need to rebuild gcc for this, right? Yes, an upgrade to the version which does not attempt to install libffi.so in /opt/csw/lib. I don't recall which version that was. Riccardo, if you decide to work on GCC on 5.9, why not build GCC 4.8? Why 4.8 and not 4.9? 4.9 has dropped Solaris 9 support: https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00728.html Maciej From maciej at opencsw.org Wed Mar 18 11:06:47 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 18 Mar 2015 10:06:47 +0000 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> <55092EBF.7010502@opencsw.org> <4A24FD39-9CA3-4251-AF9C-FD8CDD12A685@opencsw.org> Message-ID: By the way, did you see these binary releases? http://jupiterrise.com/tgcware/sunos5.9_sparc/stable/ It includes GCC 4.9.2 for Solaris 9 x86 and SPARC. From rmottola at opencsw.org Wed Mar 18 20:19:20 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 18 Mar 2015 20:19:20 +0100 Subject: missing libffi.so master link In-Reply-To: References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> <55092EBF.7010502@opencsw.org> <4A24FD39-9CA3-4251-AF9C-FD8CDD12A685@opencsw.org> Message-ID: <5509CFB8.9000804@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > 2015-03-18 8:41 GMT+00:00 Dagobert Michelsen : >> and yes, the symlink is also in gcc4core and the link is there on unstable9s: >> >>> /opt/csw/lib/libffi.so=libffi.so.4.0.1 s none CSWgcc4core >> Of course I can remove gcc3java, but we also need to take care of gcc4java. >> @Maciej: I guess I need to rebuild gcc for this, right? > Yes, an upgrade to the version which does not attempt to install > libffi.so in /opt/csw/lib. I don't recall which version that was. If you can catch that it would be fine and perhaps the best solution. > Riccardo, if you decide to work on GCC on 5.9, why not build GCC 4.8? > > Why 4.8 and not 4.9? 4.9 has dropped Solaris 9 support: > https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00728.html Actually 4.9 is reported to build on Solaris 9, both x86 and SPARC (you mention available packages) nut also on gcc website. I tried however and got a error which I will report separately. The real problem is that I don't know how to keep a separate, older version for solaris 9 in mgar. Some kind of branch? a new Package? Since "current" is 4.9 right now. This is a problem that sooner or later needs to be done anyway. Older systems will eventually diverge before you give them up. The same problem is why I did not start working on the "solaris 8 respin" (apart form the general lack of time and immense effort that getting the first gnustep package working is) Riccardo From laurent at opencsw.org Wed Mar 18 20:19:32 2015 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 18 Mar 2015 20:19:32 +0100 Subject: gcc receipe and architecture comment In-Reply-To: <20150318092934.GA4152@quince> References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> Message-ID: <5509CFC4.4090609@opencsw.org> Le 2015/03/18 10:29 +0100, Matchek a ?crit: > We had a similar rule to build for 386, where 386 didn't stand for just > Intel processors, it actually meant the 386 processor, as opposed to the > newer 486. Seriously?! When was that?! From laurent at opencsw.org Wed Mar 18 20:27:20 2015 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 18 Mar 2015 20:27:20 +0100 Subject: missing libffi.so master link In-Reply-To: <5509CFB8.9000804@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> <55092EBF.7010502@opencsw.org> <4A24FD39-9CA3-4251-AF9C-FD8CDD12A685@opencsw.org> <5509CFB8.9000804@opencsw.org> Message-ID: <5509D198.5080509@opencsw.org> Le 2015/03/18 20:19 +0100, Riccardo Mottola a ?crit: > The real problem is that I don't know how to keep a separate, older > version for solaris 9 in mgar. Some kind of branch? a new Package? Since > "current" is 4.9 right now. This is a problem that sooner or later needs > to be done anyway. Older systems will eventually diverge before you give > them up. Then don't bother with Solaris 9. > The same problem is why I did not start working on the "solaris 8 > respin" (apart form the general lack of time and immense effort that > getting the first gnustep package working is) Honestly, considering your energy, I think it's a waste to use it all on S9. Why don't you pick more worthy targets on more current systems? Laurent From maciej at opencsw.org Wed Mar 18 20:48:20 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 18 Mar 2015 19:48:20 +0000 Subject: gcc receipe and architecture comment In-Reply-To: <5509CFC4.4090609@opencsw.org> References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> <5509CFC4.4090609@opencsw.org> Message-ID: 2015-03-18 19:19 GMT+00:00 Laurent Blume : > Seriously?! When was that?! Found it, October 2011: https://sourceforge.net/p/gar/code/15950/ From rmottola at opencsw.org Wed Mar 18 20:59:31 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Wed, 18 Mar 2015 20:59:31 +0100 Subject: gcc 4.9 on solaris 9 sparc (alignment) Message-ID: <5509D923.10805@opencsw.org> Hi, while trying to build gcc 4.9 on solaris9 sparc I get the alignment errors pasted below. I did some research, people got this on older versions on solaris with old linkers, but the posts are very old. I am bootstrapping with gcc 4.6 instead. Do you have clues? ideas? It is officially reported to still build: https://gcc.gnu.org/gcc-4.9/buildstat.html Riccardo libtool: link: /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/xgcc -shared-libgcc -B/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc -nostdinc++ -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src/.libs -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/libsupc++/.libs -B/opt/csw/sparc-sun-solaris2.9/bin/ -B/opt/csw/sparc-sun-solaris2.9/lib/ -isystem /opt/csw/sparc-sun-solaris2.9/include -isystem /opt/csw/sparc-sun-solaris2.9/sys-include -shared -nostdlib /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crti.o /usr/ccs/lib/values-Xa.o /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crtbegin.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-z -Wl,allextract ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,-z -Wl,defaultextract -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/libsupc++/.libs -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/sparc-sun-solaris2.9/libstdc++-v3/src/.libs -lm -lrt -L/home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc -L/opt/csw/sparc-sun-solaris2.9/bin -L/opt/csw/sparc-sun-solaris2.9/lib -L/usr/ccs/lib -lgcc_s -lc -lgcc_s -lc /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crtend.o /home/rmottola/opencsw/gcc4/trunk/work/solaris9-sparc/build-isa-sparcv8plus/objdir/./gcc/crtn.o -Wl,-M -Wl,libstdc++-symbols.ver-sun -Wl,-h -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.20 ld: fatal: relocation error: R_SPARC_32: file .libs/compatibility.o: symbol __gxx_personality_v0: offset 0xf94df is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/compatibility-chrono.o: symbol __gxx_personality_v0: offset 0xf975f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(atexit_thread.o): symbol __gxx_personality_v0: offset 0xf981b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(eh_alloc.o): symbol __gxx_personality_v0: offset 0xf9d83 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o): symbol __gxx_personality_v0: offset 0xfa0af is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(eh_personality.o): symbol __gxx_personality_v0: offset 0xfa203 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(eh_ptr.o): symbol __gxx_personality_v0: offset 0xfa30f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(eh_terminate.o): symbol __gxx_personality_v0: offset 0xfa44b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(eh_tm.o): symbol __gxx_personality_v0: offset 0xfa57f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(guard.o): symbol __gxx_personality_v0: offset 0xfa91b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(new_opnt.o): symbol __gxx_personality_v0: offset 0xfab73 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(new_opv.o): symbol __gxx_personality_v0: offset 0xfabab is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(vec.o): symbol __gxx_personality_v0: offset 0xfaf57 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../libsupc++/.libs/libsupc++convenience.a(vterminate.o): symbol __gxx_personality_v0: offset 0xfb137 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(bitmap_allocator.o): symbol __gxx_personality_v0: offset 0xfb283 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(pool_allocator.o): symbol __gxx_personality_v0: offset 0xfbab7 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(mt_allocator.o): symbol __gxx_personality_v0: offset 0xfbec3 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(codecvt.o): symbol __gxx_personality_v0: offset 0xfc2cf is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(complex_io.o): symbol __gxx_personality_v0: offset 0xfc4bb is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ctype.o): symbol __gxx_personality_v0: offset 0xfc607 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ios.o): symbol __gxx_personality_v0: offset 0xfc857 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ios_failure.o): symbol __gxx_personality_v0: offset 0xfc97f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ios_init.o): symbol __gxx_personality_v0: offset 0xfca2b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(locale.o): symbol __gxx_personality_v0: offset 0xfce53 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(locale_init.o): symbol __gxx_personality_v0: offset 0xfd147 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(localename.o): symbol __gxx_personality_v0: offset 0xfd2c7 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(stdexcept.o): symbol __gxx_personality_v0: offset 0xfd837 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(strstream.o): symbol __gxx_personality_v0: offset 0xfdbd7 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(istream.o): symbol __gxx_personality_v0: offset 0xfe26f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(valarray.o): symbol __gxx_personality_v0: offset 0xfe4df is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ctype_members.o): symbol __gxx_personality_v0: offset 0xfe7d3 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(monetary_members.o): symbol __gxx_personality_v0: offset 0xfea03 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(numeric_members.o): symbol __gxx_personality_v0: offset 0xfeb5f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(time_members.o): symbol __gxx_personality_v0: offset 0xfec0f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(basic_file.o): symbol __gxx_personality_v0: offset 0xfed27 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(c++locale.o): symbol __gxx_personality_v0: offset 0xfee8f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ext-inst.o): symbol __gxx_personality_v0: offset 0xff24b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ios-inst.o): symbol __gxx_personality_v0: offset 0xff7b7 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(iostream-inst.o): symbol __gxx_personality_v0: offset 0xffc23 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(istream-inst.o): symbol __gxx_personality_v0: offset 0xffe5b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(locale-inst.o): symbol __gxx_personality_v0: offset 0x101063 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(misc-inst.o): symbol __gxx_personality_v0: offset 0x102d87 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(ostream-inst.o): symbol __gxx_personality_v0: offset 0x102f73 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(sstream-inst.o): symbol __gxx_personality_v0: offset 0x103b4f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(streambuf-inst.o): symbol __gxx_personality_v0: offset 0x104843 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++98/.libs/libc++98convenience.a(wlocale-inst.o): symbol __gxx_personality_v0: offset 0x1053d3 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(chrono.o): symbol __gxx_personality_v0: offset 0x106ef7 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(debug.o): symbol __gxx_personality_v0: offset 0x10707b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(functexcept.o): symbol __gxx_personality_v0: offset 0x10749f is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(future.o): symbol __gxx_personality_v0: offset 0x107817 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(regex.o): symbol __gxx_personality_v0: offset 0x107ae7 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(fstream-inst.o): symbol __gxx_personality_v0: offset 0x107f9b is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(string-inst.o): symbol __gxx_personality_v0: offset 0x108e63 is non-aligned ld: fatal: relocation error: R_SPARC_32: file ../src/c++11/.libs/libc++11convenience.a(wstring-inst.o): symbol __gxx_personality_v0: offset 0x10a013 is non-aligned collect2: error: ld returned 1 exit status gmake[6]: *** [libstdc++.la] Error 1 From laurent at opencsw.org Wed Mar 18 21:13:49 2015 From: laurent at opencsw.org (Laurent Blume) Date: Wed, 18 Mar 2015 21:13:49 +0100 Subject: gcc receipe and architecture comment In-Reply-To: References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> <5509CFC4.4090609@opencsw.org> Message-ID: <5509DC7D.6080707@opencsw.org> Le 2015/03/18 20:48 +0100, Matchek a ?crit: > 2015-03-18 19:19 GMT+00:00 Laurent Blume : >> Seriously?! When was that?! > > Found it, October 2011: https://sourceforge.net/p/gar/code/15950/ > Makes no sense. S8 did not support the 386. S7, I'm not even sure. Why settle for such a low target? Laurent From maciej at opencsw.org Wed Mar 18 21:39:21 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Wed, 18 Mar 2015 20:39:21 +0000 Subject: gcc receipe and architecture comment In-Reply-To: <5509DC7D.6080707@opencsw.org> References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> <5509CFC4.4090609@opencsw.org> <5509DC7D.6080707@opencsw.org> Message-ID: 2015-03-18 20:13 GMT+00:00 Laurent Blume : > Makes no sense. S8 did not support the 386. S7, I'm not even sure. Why > settle for such a low target? I think we were still building for Solaris 8 until shortly before that (measured in years). We stopped supporting Solaris 8 in March 2010. A year and a half. An eye blink. http://lists.opencsw.org/pipermail/announce/2010-March/000143.html There were people in the project who wanted it that way. It's somewhere in the list archives, but I searched for a few minutes and couldn't find it. Maciej From laurent at opencsw.org Thu Mar 19 09:54:28 2015 From: laurent at opencsw.org (Laurent Blume) Date: Thu, 19 Mar 2015 09:54:28 +0100 Subject: gcc receipe and architecture comment In-Reply-To: References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> <5509CFC4.4090609@opencsw.org> <5509DC7D.6080707@opencsw.org> Message-ID: <550A8EC4.6020100@opencsw.org> Le 2015/03/18 21:39 +0100, Matchek a ?crit: > I think we were still building for Solaris 8 until shortly before that > (measured in years). We stopped supporting Solaris 8 in March 2010. A > year and a half. An eye blink. But since S8 did not, ever, support the 386, it truly made zero sense, even in 2010. Even in 2000, it made no sense. The last Solaris to support the 386 was 2.5.1 (and it was not exactly a recommended CPU...) Solaris truly attracts hardcore traditionalists :-D http://docs.oracle.com/cd/E19620-01/805-4853/6j4jev6qc/index.html http://docs.oracle.com/cd/E19504-01/802-5739/6i9fpme6d/index.html http://docs.oracle.com/cd/E19504-01/802-5739/6i9fpme6c/index.html http://docs.oracle.com/cd/E19695-01/802-1960/802-1960.pdf http://docs.oracle.com/cd/E19457-01/801-6617/801-6617.pdf From rmottola at opencsw.org Thu Mar 19 19:03:16 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 19 Mar 2015 19:03:16 +0100 Subject: gcc receipe and architecture comment In-Reply-To: References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> Message-ID: <550B0F64.90706@opencsw.org> Hi, Maciej (Matchek) Blizi?ski wrote: > 2015-03-18 9:39 GMT+00:00 Dagobert Michelsen : >> I just looked and we raised the automatic buildlevel for Solaris 10 only: >> https://buildfarm.opencsw.org/trac/changeset/15907 >> >> If you build gcc for Solaris 9 you need to manually raise the buildlevel. > Why don't we do it for Solaris 9 too? > > (Will require a checkpkg code update too. We are checking for this policy.) > > One concern could be that we don't want to screw up the Solaris 9 > catalog: if we were to freeze it as is, in an old but otherwise good > state, it's better than screwing it up and leaving it in an bad state. > Rebuilding GCC should not cause that. > What are you referring to, guys? The link above doesn?t work for me, I get a 502 proxy error. Riccardo From rmottola at opencsw.org Thu Mar 19 19:12:49 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 19 Mar 2015 19:12:49 +0100 Subject: missing libffi.so master link In-Reply-To: <5509D198.5080509@opencsw.org> References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org> <22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org> <54FC3302.6000307@opencsw.org> <550745B1.903@opencsw.org> <5507F6CD.4020006@opencsw.org> <4A2A8027-B68B-4C54-A8BD-E1A0B3062363@opencsw.org> <55080D9B.5040307@opencsw.org> <7D31F7FE-A1B7-4539-AAF6-9961A1819C94@opencsw.org> <55092EBF.7010502@opencsw.org> <4A24FD39-9CA3-4251-AF9C-FD8CDD12A685@opencsw.org> <5509CFB8.9000804@opencsw.org> <5509D198.5080509@opencsw.org> Message-ID: <550B11A1.50107@opencsw.org> Hi, Laurent Blume wrote: > Le 2015/03/18 20:19 +0100, Riccardo Mottola a ?crit: >> The real problem is that I don't know how to keep a separate, older >> version for solaris 9 in mgar. Some kind of branch? a new Package? Since >> "current" is 4.9 right now. This is a problem that sooner or later needs >> to be done anyway. Older systems will eventually diverge before you give >> them up. > Then don't bother with Solaris 9. Well, I was asked why I did not build 4.8 and the question is "I don't know how to handle that"... It is an interesting thing. I hope Majei will teach me. > Honestly, considering your energy, I think it's a waste to use it all > on S9. Why don't you pick more worthy targets on more current systems? Well, I'm interested in SPARC for solaris 8 and 9. I think people with intel hardware update anyway, especially if it is non-sun hardware. Instead there are for sure many UltraSPARC machines around worthy to run software for quite a while! And also these platforms are very good for testing software. So the intel part is just because I need to :) Riccardo From maciej at opencsw.org Fri Mar 20 15:32:00 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 20 Mar 2015 14:32:00 +0000 Subject: HTTP redirects on our wordpress page Message-ID: I've turned this page into a HTTP redirection: http://www.opencsw.org/use-it/ I did it by simply editing /var/www/www.opencsw.org/htdocs/.htaccess on the web server. I also cleaned the file up, and changed RedirectMatch into a simple Redirect, where RedirectMatch was not necessary. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Fri Mar 20 15:42:54 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Fri, 20 Mar 2015 14:42:54 +0000 Subject: OpenCSW technical Wintercamp in Ilmenau In-Reply-To: References: Message-ID: Carsten et al, During the camp, could you look at this problem, and possibly improve the situation during the hacking session? http://lists.opencsw.org/pipermail/maintainers/2015-February/019637.html People often land on our package pages, and see the "Documentation" link in the context of a package, and are confused. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmottola at opencsw.org Sat Mar 21 17:25:07 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 21 Mar 2015 17:25:07 +0100 Subject: failure due to target Message-ID: <550D9B63.6010004@opencsw.org> Hi, why do I get this error on solaris 9 x86? I do not specify the architecture. I just added a patch for a known problem regarding UINTPTR_MAX. What is forcing "amd64" ICU for C/C++ 54.1 is ready to be built. === Important Notes: === Data Packaging: library This means: ICU data will be linked with ICU. A shared data library will be built. To locate data: ICU will use the linked data library. If linked with the stub library located in stubdata/, the application can use udata_setCommonData() or set a data path to override. Building ICU: Use a GNU make such as /opt/csw/bin/gmake to build ICU. checking the version of "/opt/csw/bin/gmake"... 3.82 (we wanted at least 3.80) ok [configure-modulated] complete for libicu. gmake[1]: Leaving directory `/home/rmottola/opencsw/libicu54/trunk' gmake[1]: Entering directory `/home/rmottola/opencsw/libicu54/trunk' /home/rmottola/opencsw/.buildsys/v2/gar//gar.conf.mk:502: *** The ISA 'amd64' can not be build on this kernel with the arch 'i386'. Stop. gmake[1]: Leaving directory `/home/rmottola/opencsw/libicu54/trunk' Riccardo From dam at opencsw.org Sat Mar 21 20:10:06 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 21 Mar 2015 20:10:06 +0100 Subject: failure due to target In-Reply-To: <550D9B63.6010004@opencsw.org> References: <550D9B63.6010004@opencsw.org> Message-ID: <2E44512B-22B2-4345-924B-1361871106F0@opencsw.org> Hi Riccardo, > Am 21.03.2015 um 17:25 schrieb Riccardo Mottola : > > why do I get this error on solaris 9 x86? I do not specify the architecture. I just added a patch for a known problem regarding UINTPTR_MAX. > What is forcing "amd64" > > ICU for C/C++ 54.1 is ready to be built. > === Important Notes: === > Data Packaging: library > This means: ICU data will be linked with ICU. A shared data library will be built. > To locate data: ICU will use the linked data library. If linked with the stub library located in stubdata/, the application can use udata_setCommonData() or set a data path to override. > Building ICU: Use a GNU make such as /opt/csw/bin/gmake to build ICU. > checking the version of "/opt/csw/bin/gmake"... 3.82 (we wanted at least 3.80) > ok > [configure-modulated] complete for libicu. > gmake[1]: Leaving directory `/home/rmottola/opencsw/libicu54/trunk' > gmake[1]: Entering directory `/home/rmottola/opencsw/libicu54/trunk' > /home/rmottola/opencsw/.buildsys/v2/gar//gar.conf.mk:502: *** The ISA 'amd64' can not be build on this kernel with the arch 'i386'. Stop. > gmake[1]: Leaving directory `/home/rmottola/opencsw/libicu54/trunk' That is a bit complicated: when building on Solaris 9 with BUILD64 enabled the 32 bit part is build on Solaris 9 and the 64 bit part on Solaris 10 to build a joint package which can run on Solaris 9 and 10. For this the build process jumps to another machine (are you building this on the farm?) with Solaris 10. You can disable this with something like this: BUILD64-5.10 = 1 BUILD64 = $(BUILD64-$(GAROSREL)) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From dam at opencsw.org Sat Mar 21 21:06:14 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 21 Mar 2015 21:06:14 +0100 Subject: libffi again Message-ID: Hi, the new package is missing a patch for relocation of ffi.h from /opt/csw/lib/libffi-3.2.1/include/ffi.h to /opt/csw/include/ffi.h The original location is noted correctly in libffi.pc and I see no reason to relocate it to /include as programs like Python pick it up correctly either way. I took the liberty of removing the relocation and unneeded patchfiles in r24742. The fix is needed or Python cannot be compiled. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Sat Mar 21 21:32:48 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sat, 21 Mar 2015 21:32:48 +0100 Subject: failure due to target In-Reply-To: <2E44512B-22B2-4345-924B-1361871106F0@opencsw.org> References: <550D9B63.6010004@opencsw.org> <2E44512B-22B2-4345-924B-1361871106F0@opencsw.org> Message-ID: <550DD570.8010405@opencsw.org> Hi, Dagobert Michelsen wrote: > That is a bit complicated: when building on Solaris 9 with BUILD64 enabled > the 32 bit part is build on Solaris 9 and the 64 bit part on Solaris 10 to > build a joint package which can run on Solaris 9 and 10. For this the build > process jumps to another machine (are you building this on the farm?) with > Solaris 10. You can disable this with something like this: yes this is on the buildfarm, I was experimenting on 9x and 9s machines. I learned that "mgar platforms" does all the magic, but I hoped I could build and check the single platforms. I failed to do that before committing: unstable9s fails one of the tests with a segfault... this will be a bit tougher to debug and understand I fear. I wanted to test unstable9x to see if it is a specific sparc problem or a generic solaris9 problem, before giving up. ICU is a monstrum... perhaps I should disable it in gnustep. Riccardo From maciej at opencsw.org Sat Mar 21 21:56:14 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sat, 21 Mar 2015 20:56:14 +0000 Subject: "Please provide me with a binary for " In-Reply-To: <54D74912.8050207@opencsw.org> References: <54D74912.8050207@opencsw.org> Message-ID: 2015-02-08 11:31 GMT+00:00 Riccardo Mottola : > Perhaps "Actions" could also be renamed? Some native speaker has an idea? > The meaning here is "Action on the package" not "User actions". Smething > like "Interact" ? I suggest these changes: 1. On package pages (opencsw.org/package/), remove all the links from the green navigation bar, except for the Home link. 2. Remove the "Actions" heading 3. Move "Contact maintainer" into the table above, place it right under "View bugs about " 4. Move "View files in package" into the table above 5. Add a copy/pasteable code which installs the package. Dago and I will try to make these changes tomorrow during the camp. Maciej From maciej at opencsw.org Sun Mar 22 17:35:46 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 22 Mar 2015 16:35:46 +0000 Subject: "Please provide me with a binary for " In-Reply-To: References: <54D74912.8050207@opencsw.org> Message-ID: Done in https://sourceforge.net/p/opencsw/code/685/ - what do people think? Example: http://www.opencsw.org/packages/python/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfelecan at opencsw.org Sun Mar 22 18:31:28 2015 From: pfelecan at opencsw.org (Peter FELECAN) Date: Sun, 22 Mar 2015 18:31:28 +0100 Subject: "Please provide me with a binary for " In-Reply-To: ("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun, 22 Mar 2015 16:35:46 +0000") References: <54D74912.8050207@opencsw.org> Message-ID: "Maciej (Matchek) Blizi?ski" writes: > Done in https://sourceforge.net/p/opencsw/code/685/ - what do people think? > Example: http://www.opencsw.org/packages/python/ Nice. This /usr/sbin/pkgchk -L CSWpython # list files can be done as /opt/csw/bin/pkgutil --listfile python which coherent with what's above, isn't it ? Also, saying that it must be done as root can be helpful. -- Peter From rmottola at opencsw.org Sun Mar 22 20:34:00 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 22 Mar 2015 20:34:00 +0100 Subject: libicu on solaris 9s Message-ID: <550F1928.6030006@opencsw.org> Hi, on solaris 9 sparc, I get these failures during tests. I don't get them on solaris 10, however it looks to me that the problem is more a linking problem. The symbol is an ICU symbol itself. (./letest) { api { ScriptTest ---[OK] ParameterTest gmake[2]: *** [check-local] Segmentation Fault (core dumped) gmake[2]: Leaving directory `/home/rmottola/opencsw/libicu54/trunk/work/solaris9-sparc/build-isa-sparcv9/icu/source/test/letest' --------------- ALL TESTS SUMMARY: ok: testdata intltest iotest cintltst ===== ERRS: letest If I try to execute the test manually, I get: References: <550F1928.6030006@opencsw.org> Message-ID: <550F0BE2.6050500@opencsw.org> Le 2015/03/22 20:34 +0100, Riccardo Mottola a ?crit: > ld.so.1: letest: fatal: libicule.so.54: open failed: No such file or > directory > Why would this happen (and why on solaris 9 and not 10)? Because this lib is installed on S10, and not on S9, so you're actually testing the already installed library, and not the one you just built. You could check that by running ldd on your new binaries. > perhaps some -L -R magic that is missing or anyway different in solaris 10? No, it all works as expected, except it's not what you want. Good test scripts know how to handle that by setting LD_LIBRARY_PATH. This one obviously doesn't. So it's a pointless test. Disable it. Laurent From maciej at opencsw.org Sun Mar 22 19:41:50 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Sun, 22 Mar 2015 18:41:50 +0000 Subject: How to find [easy] stuff to do In-Reply-To: References: Message-ID: 2015-01-04 23:40 GMT+00:00 Maciej (Matchek) Blizi?ski : > When I have a little more time, I'll make it run faster and I'll turn > it into a cron job. I made it a cron job, and made it available from the common space: http://buildfarm.opencsw.org/obsolete-pkgs/gar-package-status.html Maciej From rmottola at opencsw.org Mon Mar 23 01:38:40 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Mon, 23 Mar 2015 01:38:40 +0100 Subject: libicu on solaris 9s In-Reply-To: <550F0BE2.6050500@opencsw.org> References: <550F1928.6030006@opencsw.org> <550F0BE2.6050500@opencsw.org> Message-ID: <550F6090.3070703@opencsw.org> Hi, Laurent Blume wrote: > Because this lib is installed on S10, and not on S9, so you're > actually testing the already installed library, and not the one you > just built. > You could check that by running ldd on your new binaries. > >> perhaps some -L -R magic that is missing or anyway different in >> solaris 10? > > No, it all works as expected, except it's not what you want. > Good test scripts know how to handle that by setting LD_LIBRARY_PATH. > This one obviously doesn't. > > So it's a pointless test. Disable it. Well more than pointless, a badly written test. It makes sense now: On solaris 10 54 is already installed so it links and runs! But that means that actually the installed version of the library is tested, not the new one. I disabled all tests with "SKIPTEST ?= 1", I do not know how to disable a single test. Or should I try to find a way to patch and disable "letest" only? Sounds messy, however having perhaps at least some test is maybe better than no tests. Riccardo From ihsan at opencsw.org Mon Mar 23 11:48:51 2015 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 23 Mar 2015 11:48:51 +0100 Subject: Mantis Problems Message-ID: <20150323104851.GA77282@dogan.ch> Hi, Yesterday I've updated OpenSSL and other packages on www.opencsw.org. Since then, Mantis is showing an error: SYSTEM WARNING: mysql_pconnect() [function.mysql-pconnect]: Headers and client library minor version mismatch. Headers:50529 Library:50621 I'd be really happy if someone with time and the knowledge could have a look into this issue. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From wilbury at opencsw.org Mon Mar 23 11:52:37 2015 From: wilbury at opencsw.org (Juraj Lutter) Date: Mon, 23 Mar 2015 11:52:37 +0100 Subject: Mantis Problems In-Reply-To: <20150323104851.GA77282@dogan.ch> References: <20150323104851.GA77282@dogan.ch> Message-ID: <550FF075.3050605@opencsw.org> On 03/23/15 11:48, Ihsan Dogan wrote: > Hi, > > Yesterday I've updated OpenSSL and other packages on > www.opencsw.org. Since then, Mantis is showing an error: > > SYSTEM WARNING: mysql_pconnect() [function.mysql-pconnect]: > Headers and client library minor version mismatch. Headers:50529 > Library:50621 > > I'd be really happy if someone with time and the knowledge could > have a look into this issue. PHP modules have to be recompiled to match mysql client version. Or "display_errors" should be turned off :-) -- Juraj Lutter From ihsan at opencsw.org Mon Mar 23 12:01:17 2015 From: ihsan at opencsw.org (Ihsan Dogan) Date: Mon, 23 Mar 2015 12:01:17 +0100 Subject: Mantis Problems In-Reply-To: <550FF075.3050605@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> Message-ID: <20150323110117.GB77282@dogan.ch> Hi, On Monday, 23 Mar 2015 11:52 +0100, Juraj Lutter wrote: > > Yesterday I've updated OpenSSL and other packages on > > www.opencsw.org. Since then, Mantis is showing an error: > > > > SYSTEM WARNING: mysql_pconnect() [function.mysql-pconnect]: > > Headers and client library minor version mismatch. Headers:50529 > > Library:50621 > > > > I'd be really happy if someone with time and the knowledge could > > have a look into this issue. > > PHP modules have to be recompiled to match mysql client version. Or > "display_errors" should be turned off :-) display_errors is already set to "off". Hmm, well, we need an updated PHP package. ;-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From jh at opencsw.org Mon Mar 23 13:47:31 2015 From: jh at opencsw.org (Jan Holzhueter) Date: Mon, 23 Mar 2015 13:47:31 +0100 Subject: Mantis Problems In-Reply-To: <20150323110117.GB77282@dogan.ch> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> Message-ID: <55100B63.7010702@opencsw.org> Hi Am 23.03.15 um 12:01 schrieb Ihsan Dogan: > > Hmm, well, we need an updated PHP package. ;-) for the time beeing going back to a CSWlibmysqlclient18 that was build with 5.5 should work also. Greetings Jan From laurent at opencsw.org Mon Mar 23 21:04:04 2015 From: laurent at opencsw.org (Laurent Blume) Date: Mon, 23 Mar 2015 21:04:04 +0100 Subject: Mantis Problems In-Reply-To: <55100B63.7010702@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> Message-ID: <551071B4.7000208@opencsw.org> Le 2015/03/23 13:47 +0100, Jan Holzhueter a ?crit: > for the time beeing going back to a CSWlibmysqlclient18 that was build > with 5.5 should work also. Do note that this is a PHP issue. The MySQL libs are explicitly compatible, there is no reason for it to complain. There must be a way to remove that warning. PHP being famous for breakage between very minor releases, they assume everybody else is the same. Laurent From wilbury at opencsw.org Mon Mar 23 22:32:32 2015 From: wilbury at opencsw.org (Juraj Lutter) Date: Mon, 23 Mar 2015 22:32:32 +0100 Subject: Mantis Problems In-Reply-To: <551071B4.7000208@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> <551071B4.7000208@opencsw.org> Message-ID: <55108670.4000109@opencsw.org> On 03/23/2015 09:04 PM, Laurent Blume wrote: > PHP being famous for breakage between very minor releases, they assume > everybody else is the same. MySQL 5.5 vs. 5.6 is quite "major" update. -- Juraj Lutter From ihsan at opencsw.org Tue Mar 24 09:38:58 2015 From: ihsan at opencsw.org (Ihsan Dogan) Date: Tue, 24 Mar 2015 09:38:58 +0100 Subject: Mantis Problems In-Reply-To: <55100B63.7010702@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> Message-ID: <20150324083858.GB5267@dogan.ch> On Monday, 23 Mar 2015 13:47 +0100, Jan Holzhueter wrote: > > Hmm, well, we need an updated PHP package. ;-) > > for the time beeing going back to a CSWlibmysqlclient18 that was build > with 5.5 should work also. Where can I find the archive with the old packages? :-) Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From dam at opencsw.org Tue Mar 24 09:42:26 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Mar 2015 09:42:26 +0100 Subject: Mantis Problems In-Reply-To: <20150324083858.GB5267@dogan.ch> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> <20150324083858.GB5267@dogan.ch> Message-ID: Hi Ihsan, > Am 24.03.2015 um 09:38 schrieb Ihsan Dogan : > > On Monday, 23 Mar 2015 13:47 +0100, Jan Holzhueter wrote: > >>> Hmm, well, we need an updated PHP package. ;-) >> >> for the time beeing going back to a CSWlibmysqlclient18 that was build >> with 5.5 should work also. > > Where can I find the archive with the old packages? :-) You should know that ;-) https://mirror.opencsw.org/opencsw/allpkgs/ 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From laurent at opencsw.org Tue Mar 24 09:53:52 2015 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 24 Mar 2015 09:53:52 +0100 Subject: Mantis Problems In-Reply-To: <55108670.4000109@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> <551071B4.7000208@opencsw.org> <55108670.4000109@opencsw.org> Message-ID: <55112620.1000009@opencsw.org> Le 2015/03/23 22:32 +0100, Juraj Lutter a ?crit: > On 03/23/2015 09:04 PM, Laurent Blume wrote: >> PHP being famous for breakage between very minor releases, they assume >> everybody else is the same. > > MySQL 5.5 vs. 5.6 is quite "major" update. It's LIBmysql. So no, it's not a major update. That's is why the library version number has not changed. The server and the libs are very distinct. Laurent From jh at opencsw.org Tue Mar 24 10:06:24 2015 From: jh at opencsw.org (Jan Holzhueter) Date: Tue, 24 Mar 2015 10:06:24 +0100 Subject: Mantis Problems In-Reply-To: <55112620.1000009@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> <551071B4.7000208@opencsw.org> <55108670.4000109@opencsw.org> <55112620.1000009@opencsw.org> Message-ID: <55112910.7020404@opencsw.org> Hi, Am 24.03.15 um 09:53 schrieb Laurent Blume: > Le 2015/03/23 22:32 +0100, Juraj Lutter a ?crit: >> On 03/23/2015 09:04 PM, Laurent Blume wrote: >>> PHP being famous for breakage between very minor releases, they assume >>> everybody else is the same. >> >> MySQL 5.5 vs. 5.6 is quite "major" update. > > It's LIBmysql. So no, it's not a major update. That's is why the library > version number has not changed. > The server and the libs are very distinct. trying my luck with a php rebuild :) We will see. Greetings Jan From wilbury at opencsw.org Tue Mar 24 10:12:31 2015 From: wilbury at opencsw.org (Juraj Lutter) Date: Tue, 24 Mar 2015 10:12:31 +0100 Subject: Mantis Problems In-Reply-To: <55112620.1000009@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> <551071B4.7000208@opencsw.org> <55108670.4000109@opencsw.org> <55112620.1000009@opencsw.org> Message-ID: <55112A7F.3000908@opencsw.org> On 03/24/15 09:53, Laurent Blume wrote: > Le 2015/03/23 22:32 +0100, Juraj Lutter a ?crit: >> On 03/23/2015 09:04 PM, Laurent Blume wrote: >>> PHP being famous for breakage between very minor releases, they assume >>> everybody else is the same. >> MySQL 5.5 vs. 5.6 is quite "major" update. > It's LIBmysql. So no, it's not a major update. That's is why the library > version number has not changed. > The server and the libs are very distinct. > >From MySQL perspective, even a "minor" numeric version upgrade can impose MAJOR functional and/or API changes. -- Juraj Lutter From laurent at opencsw.org Tue Mar 24 10:54:00 2015 From: laurent at opencsw.org (Laurent Blume) Date: Tue, 24 Mar 2015 10:54:00 +0100 Subject: Mantis Problems In-Reply-To: <55112A7F.3000908@opencsw.org> References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> <551071B4.7000208@opencsw.org> <55108670.4000109@opencsw.org> <55112620.1000009@opencsw.org> <55112A7F.3000908@opencsw.org> Message-ID: <55113438.90503@opencsw.org> Le 2015/03/24 10:12 +0100, Juraj Lutter a ?crit: > From MySQL perspective, even a "minor" numeric version upgrade can > impose MAJOR functional and/or API changes. Let me tell you that again in bold letters: the SONAME version number has not changed and is MEANT TO BE BINARY COMPATIBLE. If you have actual concerns, please substantiate them with actual evidence rather than assertions. I have no time to try to prove negatives to you. Thank you. Laurent From dam at opencsw.org Tue Mar 24 14:06:47 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Mar 2015 14:06:47 +0100 Subject: gcc receipe and architecture comment In-Reply-To: <550B0F64.90706@opencsw.org> References: <55092F5F.6010007@opencsw.org> <20150318092934.GA4152@quince> <550B0F64.90706@opencsw.org> Message-ID: Hi Riccardo, > Am 19.03.2015 um 19:03 schrieb Riccardo Mottola : > Maciej (Matchek) Blizi?ski wrote: >> 2015-03-18 9:39 GMT+00:00 Dagobert Michelsen : >>> I just looked and we raised the automatic buildlevel for Solaris 10 only: >>> https://buildfarm.opencsw.org/trac/changeset/15907 >>> >>> If you build gcc for Solaris 9 you need to manually raise the buildlevel. >> Why don't we do it for Solaris 9 too? >> >> (Will require a checkpkg code update too. We are checking for this policy.) >> >> One concern could be that we don't want to screw up the Solaris 9 >> catalog: if we were to freeze it as is, in an old but otherwise good >> state, it's better than screwing it up and leaving it in an bad state. >> Rebuilding GCC should not cause that. > > What are you referring to, guys? The link above doesn?t work for me, I get a 502 proxy error. The machine is rather slow and you got an Apache timeout, this is increased now. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Tue Mar 24 15:38:29 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 24 Mar 2015 15:38:29 +0100 Subject: overrides specific for architecture Message-ID: <551176E5.3010100@opencsw.org> Hi, with the new libffi I can finally build gnustep-base! But packaging fails: WARNING: Some overrides did not match any errors. They can probably be removed, as they don't take any effect anyway. If you're getting errors at the same time, maybe you didn't specify your overrides correctly. * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/autogsdoc arch_id=18 arch_name=sparcv8+ * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/gdnc arch_id=18 arch_name=sparcv8+ * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/plmerge arch_id=18 arch_name=sparcv8+ * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/plser arch_id=18 arch_name=sparcv8+ * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/sfparse arch_id=18 arch_name=sparcv8+ * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/pl arch_id=18 arch_name=sparcv8+ Obviously: those overrides are specific to SPARC by definition... I'm building on intel. Do I ned to do some GARCH magic perhaps? Should I use the From dam at opencsw.org Tue Mar 24 15:39:59 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Tue, 24 Mar 2015 15:39:59 +0100 Subject: overrides specific for architecture In-Reply-To: <551176E5.3010100@opencsw.org> References: <551176E5.3010100@opencsw.org> Message-ID: <1ECF382A-A698-4142-98A3-97445C3B1052@opencsw.org> Hi Riccardo, > Am 24.03.2015 um 15:38 schrieb Riccardo Mottola : > with the new libffi I can finally build gnustep-base! > > But packaging fails: > > WARNING: Some overrides did not match any errors. They can probably be removed, > as they don't take any effect anyway. If you're getting errors at the same > time, maybe you didn't specify your overrides correctly. > * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/autogsdoc arch_id=18 arch_name=sparcv8+ > * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/gdnc arch_id=18 arch_name=sparcv8+ > * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/plmerge arch_id=18 arch_name=sparcv8+ > * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/plser arch_id=18 arch_name=sparcv8+ > * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/sfparse arch_id=18 arch_name=sparcv8+ > * Unused Override: CSWgnustep-base: binary-architecture-does-not-match-placement file=opt/csw/GNUstep/System/Tools/pl arch_id=18 arch_name=sparcv8+ > > Obviously: those overrides are specific to SPARC by definition... I'm building on intel. > > Do I ned to do some GARCH magic perhaps? No, these are warnings, it is ok to ignore warnings that apply to only one ISA. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From maciej at opencsw.org Tue Mar 24 16:40:46 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 24 Mar 2015 15:40:46 +0000 Subject: We will soon be patching yet another build system Message-ID: http://bazel.io/ Linux, OS X -------------- next part -------------- An HTML attachment was scrubbed... URL: From slowfranklin at opencsw.org Tue Mar 24 17:15:04 2015 From: slowfranklin at opencsw.org (slowfranklin) Date: Tue, 24 Mar 2015 17:15:04 +0100 Subject: We will soon be patching yet another build system In-Reply-To: References: Message-ID: <2063B79F-26C9-43B0-A408-C121A9CA9196@opencsw.org> Interesting, thanks for the pointer! Looks like a promising alternative to waf for Samba. Has this just been publicly released? Cheerio! -slow > Am 24.03.2015 um 16:40 schrieb Maciej (Matchek) Blizi?ski : > > http://bazel.io/ > > Linux, OS X From maciej at opencsw.org Tue Mar 24 19:21:55 2015 From: maciej at opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?=) Date: Tue, 24 Mar 2015 18:21:55 +0000 Subject: We will soon be patching yet another build system In-Reply-To: <2063B79F-26C9-43B0-A408-C121A9CA9196@opencsw.org> References: <2063B79F-26C9-43B0-A408-C121A9CA9196@opencsw.org> Message-ID: 2015-03-24 16:15 GMT+00:00 slowfranklin : > Interesting, thanks for the pointer! Looks like a promising alternative to waf for Samba. Cool! > Has this just been publicly released? Yes. I have no idea how much work would it need to make it run on Solaris. Maciej From rmottola at opencsw.org Tue Mar 24 22:59:00 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 24 Mar 2015 22:59:00 +0100 Subject: overrides specific for architecture In-Reply-To: <1ECF382A-A698-4142-98A3-97445C3B1052@opencsw.org> References: <551176E5.3010100@opencsw.org> <1ECF382A-A698-4142-98A3-97445C3B1052@opencsw.org> Message-ID: <5511DE24.3090805@opencsw.org> Hi, Dagobert Michelsen wrote: > No, these are warnings, it is ok to ignore warnings that apply to only > one ISA. right, I did not see in the plethora of warnings that I missed exactly the same overrides for i386... Riccardo From rmottola at opencsw.org Thu Mar 26 09:00:12 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Thu, 26 Mar 2015 09:00:12 +0100 Subject: latest version of libpng Message-ID: <5513BC8C.9020305@opencsw.org> Hi, I'm confused about our libpng versions! lrwxrwxrwx 1 root root 11 Nov 11 2012 /opt/csw/lib/libpng.so -> libpng15.so lrwxrwxrwx 1 root root 16 Sep 18 2012 /opt/csw/lib/libpng.so.3 -> libpng.so.3.50.0 -rwxr-xr-x 1 root bin 210396 Sep 18 2012 /opt/csw/lib/libpng.so.3.50.0 lrwxrwxrwx 1 root root 18 Sep 18 2012 /opt/csw/lib/libpng12.so.0 -> libpng12.so.0.50.0 -rwxr-xr-x 1 root bin 200752 Sep 18 2012 /opt/csw/lib/libpng12.so.0.50.0 lrwxrwxrwx 1 root root 19 Nov 11 2012 /opt/csw/lib/libpng15.so -> libpng15.so.15.13.0 lrwxrwxrwx 1 root root 19 Nov 11 2012 /opt/csw/lib/libpng15.so.15 -> libpng15.so.15.13.0 -rwxr-xr-x 1 root bin 234128 Nov 10 2012 /opt/csw/lib/libpng15.so.15.13.0 we have versoned names for 12 and 15 but what is libpng.so.3 which would look as the correct one? I see the series a 1.0, 1.2, 1.5... On my own box I and up having libpng3.. Just to know about this oddity. There are some security updates, I'll try my best updating libpng, but wanted to now this oddity first. Riccardo From pfelecan at opencsw.org Thu Mar 26 19:42:03 2015 From: pfelecan at opencsw.org (Peter FELECAN) Date: Thu, 26 Mar 2015 19:42:03 +0100 Subject: latest version of libpng In-Reply-To: <5513BC8C.9020305@opencsw.org> (Riccardo Mottola's message of "Thu, 26 Mar 2015 09:00:12 +0100") References: <5513BC8C.9020305@opencsw.org> Message-ID: Riccardo Mottola writes: > lrwxrwxrwx 1 root root 16 Sep 18 2012 > /opt/csw/lib/libpng.so.3 -> libpng.so.3.50.0 what yelds "pkgchk -l -p /opt/csw/lib/libpng.so.3" ? -- Peter From dam at opencsw.org Fri Mar 27 10:53:21 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Fri, 27 Mar 2015 10:53:21 +0100 Subject: latest version of libpng In-Reply-To: <5513BC8C.9020305@opencsw.org> References: <5513BC8C.9020305@opencsw.org> Message-ID: <843461A1-F571-4D10-9712-557D0AF905F6@opencsw.org> Hi Riccardo, > Am 26.03.2015 um 09:00 schrieb Riccardo Mottola : > > I'm confused about our libpng versions! > > lrwxrwxrwx 1 root root 11 Nov 11 2012 /opt/csw/lib/libpng.so -> libpng15.so > lrwxrwxrwx 1 root root 16 Sep 18 2012 /opt/csw/lib/libpng.so.3 -> libpng.so.3.50.0 > -rwxr-xr-x 1 root bin 210396 Sep 18 2012 /opt/csw/lib/libpng.so.3.50.0 > lrwxrwxrwx 1 root root 18 Sep 18 2012 /opt/csw/lib/libpng12.so.0 -> libpng12.so.0.50.0 > -rwxr-xr-x 1 root bin 200752 Sep 18 2012 /opt/csw/lib/libpng12.so.0.50.0 > lrwxrwxrwx 1 root root 19 Nov 11 2012 /opt/csw/lib/libpng15.so -> libpng15.so.15.13.0 > lrwxrwxrwx 1 root root 19 Nov 11 2012 /opt/csw/lib/libpng15.so.15 -> libpng15.so.15.13.0 > -rwxr-xr-x 1 root bin 234128 Nov 10 2012 /opt/csw/lib/libpng15.so.15.13.0 > > we have versoned names for 12 and 15 but what is libpng.so.3 which would look as the correct one? I see the series a 1.0, 1.2, 1.5? That is 1.2.50: > dam at unstable10s [unstable10s]:/home/dam > pkginfo -x CSWlibpng3 CSWlibpng12-0 CSWlibpng15-15 > CSWlibpng3 libpng3 - The official library for Portable Network Graphics format (PNG), libpng.so.3 > (sparc) 1.2.50,REV=2012.09.18 > CSWlibpng12-0 libpng12_0 - The official library for Portable Network Graphics format (PNG), libpng12.so.0 > (sparc) 1.2.50,REV=2012.09.18 > CSWlibpng15-15 libpng15_15 - The official library for Portable Network Graphics format (PNG), libpng15.so.15 > (sparc) 1.5.13,REV=2012.11.10 libpng.so.3 and libpng12.so.0 are produced by the same recipe: https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/libpng/branches/libpng3/Makefile This seems like the same library due to upstream rename. > On my own box I and up having libpng3.. Just to know about this oddity. > > There are some security updates, I'll try my best updating libpng, but wanted to now this oddity first. If you don?t introduce another soname it should be fine, otherwise the same restrictions apply as to e.g. the OpenSSL transition: http://wiki.opencsw.org/project-openssl Although it should be less of a problem now due to direct linking, but AFAIK this has not been tested enough. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From ihsan at opencsw.org Fri Mar 27 14:29:01 2015 From: ihsan at opencsw.org (Ihsan Dogan) Date: Fri, 27 Mar 2015 14:29:01 +0100 Subject: Mantis Problems In-Reply-To: References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org> <20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org> <20150324083858.GB5267@dogan.ch> Message-ID: <20150327132901.GB34706@dogan.ch> On Tuesday, 24 Mar 2015 09:42 +0100, Dagobert Michelsen wrote: > >>> Hmm, well, we need an updated PHP package. ;-) > >> for the time beeing going back to a CSWlibmysqlclient18 that was build > >> with 5.5 should work also. > > Where can I find the archive with the old packages? :-) > > You should know that ;-) > > https://mirror.opencsw.org/opencsw/allpkgs/ Hmm, well, yes, I should. :-) Thanks Dago! I've installed the previous CSWlibmysqlclient18 and the error message is now gone. Ihsan -- ihsan at dogan.ch http://blog.dogan.ch/ From rmottola at opencsw.org Fri Mar 27 17:11:26 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Fri, 27 Mar 2015 17:11:26 +0100 Subject: latest version of libpng In-Reply-To: <843461A1-F571-4D10-9712-557D0AF905F6@opencsw.org> References: <5513BC8C.9020305@opencsw.org> <843461A1-F571-4D10-9712-557D0AF905F6@opencsw.org> Message-ID: <5515812E.3080308@opencsw.org> Hi, On 03/27/15 10:53, Dagobert Michelsen wrote: > Hi Riccardo, > > libpng.so.3 and libpng12.so.0 are produced by the same recipe: > https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/libpng/branches/libpng3/Makefile > This seems like the same library due to upstream rename. I understand, so it was upstream that caused this confusion! thanks. I just went to use 15 which is current, while I work on 16 > >> On my own box I and up having libpng3.. Just to know about this oddity. >> >> There are some security updates, I'll try my best updating libpng, but wanted to now this oddity first. > If you don?t introduce another soname it should be fine, otherwise the same restrictions apply > as to e.g. the OpenSSL transition: > http://wiki.opencsw.org/project-openssl > Although it should be less of a problem now due to direct linking, but AFAIK this has not been > tested enough. what do you mean by "soname change"? I see that libpng15 introduced a new soname, bu hides it with a link so libpng.so is then linked to libpng15.so.15.13.0 I thought of adding libpng16.so.16.xxx to follow this reasoning. Riccardo From dam at opencsw.org Sat Mar 28 22:23:30 2015 From: dam at opencsw.org (Dagobert Michelsen) Date: Sat, 28 Mar 2015 22:23:30 +0100 Subject: latest version of libpng In-Reply-To: <5515812E.3080308@opencsw.org> References: <5513BC8C.9020305@opencsw.org> <843461A1-F571-4D10-9712-557D0AF905F6@opencsw.org> <5515812E.3080308@opencsw.org> Message-ID: <2E783FC6-F107-4D26-A1C6-94BE8375E3A1@opencsw.org> Hi Riccardo, > Am 27.03.2015 um 17:11 schrieb Riccardo Mottola : >>> On my own box I and up having libpng3.. Just to know about this oddity. >>> >>> There are some security updates, I'll try my best updating libpng, but wanted to now this oddity first. >> If you don?t introduce another soname it should be fine, otherwise the same restrictions apply >> as to e.g. the OpenSSL transition: >> http://wiki.opencsw.org/project-openssl >> Although it should be less of a problem now due to direct linking, but AFAIK this has not been >> tested enough. > > what do you mean by "soname change"? I see that libpng15 introduced a new soname, bu hides it with a link > > so libpng.so is then linked to libpng15.so.15.13.0 > > I thought of adding libpng16.so.16.xxx to follow this reasoning. Essentially yes, the reasing is explained here: http://www.opencsw.org/manual/for-maintainers/shared-libraries.html 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From rmottola at opencsw.org Sun Mar 29 19:04:04 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 29 Mar 2015 19:04:04 +0200 Subject: problem uploading a package due to solaris 11 Message-ID: Hi, when I try to upload my new gnustep-back packages, I get: Checking 1 package against catalog unstable i386 SunOS5.10 Checking 1 package against catalog unstable sparc SunOS5.10 Checking 1 package against catalog unstable i386 SunOS5.11 Checking 1 package against catalog unstable sparc SunOS5.11 Checks failed for the following catalogs: - sparc SunOS5.11 gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz To see the errors, run: /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py --catalog-release unstable --os-release SunOS5.11 --catalog-architecture sparc f72ad449eda9058e2f3b0f9f2852e881 Your packages have not been submitted to the unstable catalog. The error says: Traceback (most recent call last): File "/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", line 16, in from lib.python import checkpkg_lib ImportError: No module named lib.python Riccardo From maciej at opencsw.org Sun Mar 29 19:10:00 2015 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Sun, 29 Mar 2015 18:10:00 +0100 Subject: problem uploading a package due to solaris 11 In-Reply-To: References: Message-ID: <20150329171000.GA5734@cotton.home.blizinski.pl> On Sun, Mar 29, 2015 at 07:04:04PM +0200, Riccardo Mottola wrote: > Hi, > > when I try to upload my new gnustep-back packages, I get: > > Checking 1 package against catalog unstable i386 SunOS5.10 > Checking 1 package against catalog unstable sparc SunOS5.10 > Checking 1 package against catalog unstable i386 SunOS5.11 > Checking 1 package against catalog unstable sparc SunOS5.11 > Checks failed for the following catalogs: > - sparc SunOS5.11 > gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz > To see the errors, run: > /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py > --catalog-release unstable --os-release SunOS5.11 --catalog-architecture > sparc f72ad449eda9058e2f3b0f9f2852e881 > Your packages have not been submitted to the unstable catalog. > > The error says: > > Traceback (most recent call last): > File "/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", > line 16, in > from lib.python import checkpkg_lib > ImportError: No module named lib.python The immediate problem is that Python needs to find its libraries, and the paths to libraries need to be passed via the PYTHONPATH env variable. export PYTHONPATH=.../path/to/gar It could be "~/opencsw/.buildsys". Another possibility to see the error tags is via http, using the md5 sum to identify your package: http://buildfarm.opencsw.org/pkgdb/srv4/f72ad449eda9058e2f3b0f9f2852e881/ Maciej From rmottola at opencsw.org Sun Mar 29 21:58:14 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Sun, 29 Mar 2015 21:58:14 +0200 Subject: problem uploading a package due to solaris 11 In-Reply-To: <20150329171000.GA5734@cotton.home.blizinski.pl> References: <20150329171000.GA5734@cotton.home.blizinski.pl> Message-ID: <55185956.1000108@opencsw.org> On 03/29/15 19:10, Maciej Blizi?ski wrote: > On Sun, Mar 29, 2015 at 07:04:04PM +0200, Riccardo Mottola wrote: >> Hi, >> >> when I try to upload my new gnustep-back packages, I get: >> >> Checking 1 package against catalog unstable i386 SunOS5.10 >> Checking 1 package against catalog unstable sparc SunOS5.10 >> Checking 1 package against catalog unstable i386 SunOS5.11 >> Checking 1 package against catalog unstable sparc SunOS5.11 >> Checks failed for the following catalogs: >> - sparc SunOS5.11 >> gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz >> To see the errors, run: >> /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py >> --catalog-release unstable --os-release SunOS5.11 --catalog-architecture >> sparc f72ad449eda9058e2f3b0f9f2852e881 >> Your packages have not been submitted to the unstable catalog. >> >> The error says: >> >> Traceback (most recent call last): >> File "/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", >> line 16, in >> from lib.python import checkpkg_lib >> ImportError: No module named lib.python > The immediate problem is that Python needs to find its libraries, and > the paths to libraries need to be passed via the PYTHONPATH env > variable. > > export PYTHONPATH=.../path/to/gar > > It could be "~/opencsw/.buildsys". > > Another possibility to see the error tags is via http, using the md5 > sum to identify your package: > http://buildfarm.opencsw.org/pkgdb/srv4/f72ad449eda9058e2f3b0f9f2852e881/ It would be nice if that URL could be "spit out" when the error happens. So many "tricks" here I forget. In the log I see: soname-not-found libXcursor.so.1 is needed by opt/csw/GNUstep/System/Library/Bundles/libgnustep-back-024.bundle/libgnustep-back-024 does this mean I need an added dependency or override which is not detected on 10 but is on 11? why? I have no clue how the check on solaris 11 is done compared to 11. An answer then could tell what action is needed. Thank you, Riccardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej at opencsw.org Sun Mar 29 22:33:29 2015 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Sun, 29 Mar 2015 21:33:29 +0100 Subject: problem uploading a package due to solaris 11 In-Reply-To: <55185956.1000108@opencsw.org> References: <20150329171000.GA5734@cotton.home.blizinski.pl> <55185956.1000108@opencsw.org> Message-ID: <20150329203329.GB15776@quince> On Sun, Mar 29, 2015 at 09:58:14PM +0200, Riccardo Mottola wrote: > On 03/29/15 19:10, Maciej Blizi?ski wrote: > >On Sun, Mar 29, 2015 at 07:04:04PM +0200, Riccardo Mottola wrote: > >>Hi, > >> > >>when I try to upload my new gnustep-back packages, I get: > >> > >>Checking 1 package against catalog unstable i386 SunOS5.10 > >>Checking 1 package against catalog unstable sparc SunOS5.10 > >>Checking 1 package against catalog unstable i386 SunOS5.11 > >>Checking 1 package against catalog unstable sparc SunOS5.11 > >>Checks failed for the following catalogs: > >> - sparc SunOS5.11 > >> gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz > >>To see the errors, run: > >> /home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py > >>--catalog-release unstable --os-release SunOS5.11 --catalog-architecture > >>sparc f72ad449eda9058e2f3b0f9f2852e881 > >>Your packages have not been submitted to the unstable catalog. > >> > >>The error says: > >> > >>Traceback (most recent call last): > >> File "/home/rmottola/opencsw/.buildsys/v2/bin/../lib/python/checkpkg2.py", > >>line 16, in > >> from lib.python import checkpkg_lib > >>ImportError: No module named lib.python > >The immediate problem is that Python needs to find its libraries, and > >the paths to libraries need to be passed via the PYTHONPATH env > >variable. > > > >export PYTHONPATH=.../path/to/gar > > > >It could be "~/opencsw/.buildsys". > > > >Another possibility to see the error tags is via http, using the md5 > >sum to identify your package: > >http://buildfarm.opencsw.org/pkgdb/srv4/f72ad449eda9058e2f3b0f9f2852e881/ > It would be nice if that URL could be "spit out" when the error happens. So > many "tricks" here I forget. Feel free to adjust the code to do that, and submit. You can grep for "To see the errors" in ~/opencsw/.buildsys to find the place where the suggestion is printed to screen. > In the log I see: > soname-not-found > > libXcursor.so.1 is needed by opt/csw/GNUstep/System/Library/Bundles/libgnustep-back-024.bundle/libgnustep-back-024 > > does this mean I need an added dependency or override which is not detected > on 10 but is on 11? why? > > I have no clue how the check on solaris 11 is done compared to 11. > > An answer then could tell what action is needed. Checks are done the same way on all systems. Checkpkg has an list of shared libraries on all Solaris versions, and when a library says it needs, say, libfoo.so.1, checkpkg tries to see if that library would be found. When it doesn't find that library, it prints this message. There can be false positives, for example checkpkg can't know about LD_LIBRARY_PATH or other tricks done at runtime. If you can, try to figure out what happens with libgnustep-back-024 on Solaris 11 (ssh unstable11s; ldd .../libgnustep-back-024). Also, does the functionality from libgnustep-back-024 run correctly on S11? If so, you can add an override. Maciej From rmottola at opencsw.org Tue Mar 31 09:13:17 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 31 Mar 2015 09:13:17 +0200 Subject: problem uploading a package due to solaris 11 In-Reply-To: <20150329203329.GB15776@quince> References: <20150329171000.GA5734@cotton.home.blizinski.pl> <55185956.1000108@opencsw.org> <20150329203329.GB15776@quince> Message-ID: <551A490D.8060003@opencsw.org> Hi Maciej, the error we are investigating is: soname-not-found libXcursor.so.1 is needed by opt/csw/GNUstep/System/Library/Bundles/libgnustep-back-024.bundle/libgnustep-back-024 Maciej Blizi?ski wrote: > Checks are done the same way on all systems. Checkpkg has an list of > shared libraries on all Solaris versions, and when a library says it > needs, say, libfoo.so.1, checkpkg tries to see if that library would be > found. When it doesn't find that library, it prints this message. > > There can be false positives, for example checkpkg can't know about > LD_LIBRARY_PATH or other tricks done at runtime. > > If you can, try to figure out what happens with libgnustep-back-024 on > Solaris 11 (ssh unstable11s; ldd .../libgnustep-back-024). > > Also, does the functionality from libgnustep-back-024 run correctly on > S11? If so, you can add an override. > > Maciej > here the output of ldd on untable10s (without runnin the GNUtep.sh script, so GS intern libraries are missing): ./trunk/work/solaris10-sparc/pkgroot/opt/csw/GNUstep/System/Library/Bundles/libgnustep-back-024.bundle/libgnustep-back-024 libcairo.so.2 => /opt/csw/lib/libcairo.so.2 libfreetype.so.6 => /opt/csw/lib/libfreetype.so.6 libXrender.so.1 => /opt/csw/lib/libXrender.so.1 libXext.so.0 => /usr/openwin/lib/libXext.so.0 libX11.so.4 => /usr/openwin/lib/libX11.so.4 libXft.so.2 => /usr/openwin/lib/libXft.so.2 libfontconfig.so.1 => /opt/csw/lib/libfontconfig.so.1 libXcursor.so.1 => /usr/lib/libXcursor.so.1 libXmu.so.4 => /usr/openwin/lib/libXmu.so.4 libXt.so.4 => /usr/openwin/lib/libXt.so.4 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libGL.so.1 => /usr/openwin/lib/libGL.so.1 libgnustep-gui.so.0.24 => (file not found) libgnustep-base.so.1.24 => (file not found) libobjc.so.4 => /opt/csw/lib/libobjc.so.4 libm.so.2 => /lib/libm.so.2 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libpixman-1.so.0 => /opt/csw/lib/sparcv8/libpixman-1.so.0 libpng15.so.15 => /opt/csw/lib/sparcv8plus+vis2/libpng15.so.15 libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 librt.so.1 => /lib/librt.so.1 libbz2.so.1.0 => /opt/csw/lib/sparcv8/libbz2.so.1.0 libXrender.so.1 => /usr/sfw/lib/libXrender.so.1 libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 libexpat.so.0 => /usr/sfw/lib/libexpat.so.0 libfreetype.so.6 => /usr/sfw/lib/libfreetype.so.6 libexpat.so.1 => /opt/csw/lib/sparcv8/libexpat.so.1 libXfixes.so.1 => /usr/openwin/sfw/lib/libXfixes.so.1 libSM.so.6 => /usr/openwin/lib/libSM.so.6 libICE.so.6 => /usr/openwin/lib/libICE.so.6 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libdga.so.1 => /usr/openwin/lib/libdga.so.1 libm.so.1 => /lib/libm.so.1 libaio.so.1 => /lib/libaio.so.1 libz.so.1 => /usr/lib/libz.so.1 libdl.so.1 => /lib/libdl.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 /platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1 /platform/SUNW,SPARC-Enterprise-T5220/lib/libmd_psr.so.1 libcursor is mapped to: libXcursor.so.1 => /usr/lib/libXcursor.so.1 if I login on unstable11s I see: libcairo.so.2 => /opt/csw/lib/libcairo.so.2 libfreetype.so.6 => /opt/csw/lib/libfreetype.so.6 libXrender.so.1 => /usr/openwin/lib/libXrender.so.1 libXext.so.0 => /usr/openwin/lib/libXext.so.0 libX11.so.4 => /usr/openwin/lib/libX11.so.4 libXft.so.2 => /usr/openwin/lib/libXft.so.2 libfontconfig.so.1 => /opt/csw/lib/libfontconfig.so.1 libXcursor.so.1 => /usr/openwin/lib/libXcursor.so.1 libXmu.so.4 => /usr/openwin/lib/libXmu.so.4 libXt.so.4 => /usr/openwin/lib/libXt.so.4 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libGL.so.1 => /opt/csw/lib/libGL.so.1 libgnustep-gui.so.0.24 => (file not found) libgnustep-base.so.1.24 => (file not found) libobjc.so.4 => /opt/csw/lib/libobjc.so.4 libm.so.2 => /lib/libm.so.2 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libpixman-1.so.0 => /opt/csw/lib/sparcv8/libpixman-1.so.0 libpng15.so.15 => /opt/csw/lib/sparcv8plus+vis2/libpng15.so.15 libXrender.so.1 => /opt/csw/lib/sparcv8/libXrender.so.1 libz.so.1 => /opt/csw/lib/sparcv8plus+vis/libz.so.1 librt.so.1 => /lib/librt.so.1 libbz2.so.1.0 => /opt/csw/lib/sparcv8/libbz2.so.1.0 libxcb.so.1 => /usr/lib/libxcb.so.1 libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 libfreetype.so.6 => /usr/lib/libfreetype.so.6 libexpat.so.1 => /opt/csw/lib/sparcv8/libexpat.so.1 libXfixes.so.1 => /usr/lib/libXfixes.so.1 libSM.so.6 => /usr/lib/libSM.so.6 libICE.so.6 => /usr/lib/libICE.so.6 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libm.so.1 => /lib/libm.so.1 libXau.so.6 => /usr/lib/libXau.so.6 libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 libexpat.so.1 => /usr/lib/libexpat.so.1 libz.so.1 => /usr/lib/libz.so.1 libbz2.so.1 => /usr/lib/libbz2.so.1 libsoftcrypto.so.1 => /lib/libsoftcrypto.so.1 libelf.so.1 => /lib/libelf.so.1 libcryptoutil.so.1 => /lib/libcryptoutil.so.1 libXevie.so.1 => /usr/lib/libXevie.so.1 libXss.so.1 => /usr/lib/libXss.so.1 libXmuu.so.1 => /usr/lib/libXmuu.so.1 xcursor is resolved: libXcursor.so.1 => /usr/openwin/lib/libXcursor.so.1 it is resolved to a different place in solaris11s, perhaps checkpkg doesn't know about that? Riccardo PS: About running on unstable11s. To be honest I haven't tested anything yet, I have packaged the three ore gnustep libraries with this, afterwards I actually need to package an application! I don't know how to export X11 display thorugh two ssh hosts ad thus "live test" I would test on my home machine, which runs 10, but currently this package fails to build/package there. It does package on unstable10s and unstable10x, so my box at home must have something different in how mgar runs. From rmottola at opencsw.org Tue Mar 31 15:50:24 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 31 Mar 2015 15:50:24 +0200 Subject: problem uploading a package due to solaris 11 In-Reply-To: <20150329171000.GA5734@cotton.home.blizinski.pl> References: <20150329171000.GA5734@cotton.home.blizinski.pl> Message-ID: <551AA620.7040705@opencsw.org> Hi, Maciej Blizi?ski wrote: > Another possibility to see the error tags is via http, using the md5 > sum to identify your package: > http://buildfarm.opencsw.org/pkgdb/srv4/f72ad449eda9058e2f3b0f9f2852e881/ I think I wrote my first 3 lines of python of my life, but I hope it works and is appreciated. The current case contains only one md5 sum, so it was easy, but it should spit one URL for each. R From pfelecan at opencsw.org Tue Mar 31 19:35:43 2015 From: pfelecan at opencsw.org (Peter FELECAN) Date: Tue, 31 Mar 2015 19:35:43 +0200 Subject: problem uploading a package due to solaris 11 In-Reply-To: <551A490D.8060003@opencsw.org> (Riccardo Mottola's message of "Tue, 31 Mar 2015 09:13:17 +0200") References: <20150329171000.GA5734@cotton.home.blizinski.pl> <55185956.1000108@opencsw.org> <20150329203329.GB15776@quince> <551A490D.8060003@opencsw.org> Message-ID: Riccardo Mottola writes: > PS: About running on unstable11s. To be honest I haven't tested > anything yet, I have packaged the three ore gnustep libraries with > this, afterwards I actually need to package an application! > I don't know how to export X11 display thorugh two ssh hosts ad thus > "live test" ssh -X rmottola at login.opencsw.org This, if the ssh server on login forwards X11. > I would test on my home machine, which runs 10, but currently this > package fails to build/package there. It does package on unstable10s > and unstable10x, so my box at home must have something different in > how mgar runs. setting up a build farm is possible even though not so easy. But it's documented. -- Peter From rmottola at opencsw.org Tue Mar 31 22:10:29 2015 From: rmottola at opencsw.org (Riccardo Mottola) Date: Tue, 31 Mar 2015 22:10:29 +0200 Subject: problem uploading a package due to solaris 11 In-Reply-To: References: <20150329171000.GA5734@cotton.home.blizinski.pl> <55185956.1000108@opencsw.org> <20150329203329.GB15776@quince> <551A490D.8060003@opencsw.org> Message-ID: <551AFF35.4070306@opencsw.org> Hi, Peter FELECAN wrote: > Riccardo Mottola writes: > >> PS: About running on unstable11s. To be honest I haven't tested >> anything yet, I have packaged the three ore gnustep libraries with >> this, afterwards I actually need to package an application! >> I don't know how to export X11 display thorugh two ssh hosts ad thus >> "live test" > ssh -X rmottola at login.opencsw.org > > This, if the ssh server on login forwards X11. Yes, it does. I did export an editor sometimes. and then then I do ssh -X unstable10x ? It is that part that is not working for me. > setting up a build farm is possible even though not so easy. But it's > documented. I don't have a full one, but I am able to build "uncommited" packages, I prepared most of the gnustep packages. I found out what is not working, a tool is wrongly detected, but this has an effect only on my system and not on the buildfarm. Anyway, I want to understand this solaris 11 library location problem. Then I will ask you guys help about this tool and do a respin of the gnustep packages. As soon as unstable9 work again I'll complete the new libpng and that needs a recompile anyway. Thanks, Riccardo From maciej at opencsw.org Tue Mar 31 22:57:18 2015 From: maciej at opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?=) Date: Tue, 31 Mar 2015 21:57:18 +0100 Subject: problem uploading a package due to solaris 11 In-Reply-To: <551AA620.7040705@opencsw.org> References: <20150329171000.GA5734@cotton.home.blizinski.pl> <551AA620.7040705@opencsw.org> Message-ID: <20150331205718.GA5151@quince> On Tue, Mar 31, 2015 at 03:50:24PM +0200, Riccardo Mottola wrote: > Hi, > > Maciej Blizi?ski wrote: > >Another possibility to see the error tags is via http, using the md5 > >sum to identify your package: > >http://buildfarm.opencsw.org/pkgdb/srv4/f72ad449eda9058e2f3b0f9f2852e881/ > I think I wrote my first 3 lines of python of my life, but I hope it works > and is appreciated. > The current case contains only one md5 sum, so it was easy, but it should > spit one URL for each. Cool, good call with the loop. One thing to watch out for in Python is to avoid mixing tabs and spaces. In our code, I've used spaces only. Maciej -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: