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: <D477BBCA-3888-4E56-AD72-EB992B3E2EEF@opencsw.org>

Hi Riccardo,

> Am 01.03.2015 um 23:50 schrieb Riccardo Mottola <rmottola at 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?

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150302/7b33b2ce/attachment.p7s>

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: <D477BBCA-3888-4E56-AD72-EB992B3E2EEF@opencsw.org>
References: <54F397D3.9010908@opencsw.org>
	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@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>	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@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>	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@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>	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@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>
	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@opencsw.org>
	<54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org>
	<54F61407.9090109@opencsw.org> <54F63516.9090904@opencsw.org>
Message-ID: <CALtRa-5KiucDcQRqMbqwr-bjxmiNAnN615g9JphrvAkxXda0zQ@mail.gmail.com>

2015-03-03 22:26 GMT+00:00 Laurent Blume <laurent at opencsw.org>:
> 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: <CALtRa-5KiucDcQRqMbqwr-bjxmiNAnN615g9JphrvAkxXda0zQ@mail.gmail.com>
References: <54F397D3.9010908@opencsw.org>
	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@opencsw.org>
	<54F4D316.9070502@opencsw.org> <54F58554.8060302@opencsw.org>
	<54F61407.9090109@opencsw.org> <54F63516.9090904@opencsw.org>
	<CALtRa-5KiucDcQRqMbqwr-bjxmiNAnN615g9JphrvAkxXda0zQ@mail.gmail.com>
Message-ID: <CALtRa-5XxaAJpPc-EfMGSM34e=8AN3H0ryvZEbWHXguLjQJCCg@mail.gmail.com>

2015-03-03 22:55 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 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>	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@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>	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@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: <CALtRa-5XxaAJpPc-EfMGSM34e=8AN3H0ryvZEbWHXguLjQJCCg@mail.gmail.com>
References: <54F397D3.9010908@opencsw.org>	<D477BBCA-3888-4E56-AD72-EB992B3E2EEF@opencsw.org>	<54F4D316.9070502@opencsw.org>
	<54F58554.8060302@opencsw.org>	<54F61407.9090109@opencsw.org>
	<54F63516.9090904@opencsw.org>	<CALtRa-5KiucDcQRqMbqwr-bjxmiNAnN615g9JphrvAkxXda0zQ@mail.gmail.com>
	<CALtRa-5XxaAJpPc-EfMGSM34e=8AN3H0ryvZEbWHXguLjQJCCg@mail.gmail.com>
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 <maciej at opencsw.org>:
>> 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: <CALtRa-71RVdbo93anbKW=u9ugXvP4106gfM84UqCXhsrpV6svA@mail.gmail.com>

2015-03-05 16:57 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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: <CALtRa-4e_DYqty233JWgiKnGAir07dQ7yw-S7B4vxBqd4riw4Q@mail.gmail.com>

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150305/3cd95038/attachment.html>

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: <BCA2FDB7-2EF5-43E6-9689-D862A1163AD9@opencsw.org>

Hi folks,

> Am 05.03.2015 um 21:11 schrieb Laurent Blume <laurent at 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.

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150305/94762a0e/attachment.p7s>

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: <bf3dfb3b78e7.54f96dea@contac-dt.de>
References: <bf3dfc123924.54f967bb@contac-dt.de>
	<bf3db9d761d.54f96835@contac-dt.de>
	<bf3de4fa70a1.54f96872@contac-dt.de>
	<bf3d92b8223f.54f968b1@contac-dt.de>
	<bf3d97165304.54f968f0@contac-dt.de>
	<bf3dc4364795.54f9692c@contac-dt.de>
	<bf3d9bdd5450.54f96968@contac-dt.de>
	<bf3dece72ae5.54f969a7@contac-dt.de>
	<bf3db83d5339.54f969e4@contac-dt.de>
	<bf3dafcb257.54f96a20@contac-dt.de> <bf3da416f04.54f96a98@contac-dt.de>
	<bf3dc5813f0d.54f96c7b@contac-dt.de>
	<bf3dbfb66965.54f96cb8@contac-dt.de>
	<bf3d90de751c.54f96cf7@contac-dt.de>
	<bf3d9fe31514.54f96d33@contac-dt.de>
	<bf3d81bda11.54f96dae@contac-dt.de>
	<bf3dfb3b78e7.54f96dea@contac-dt.de>
Message-ID: <bf3dc1152a0d.54f97c1f@contac-dt.de>

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150306/c17e2923/attachment.html>

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: <x6lhjaxoig.fsf@opencsw.org>

Riccardo Mottola <rmottola at opencsw.org> 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: <CALtRa-7AHi2rODoCmSxXoqprgYZgtwLNL5y4jKAGFkV7718GQA@mail.gmail.com>

2015-03-07 9:02 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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: <CALtRa-7AHi2rODoCmSxXoqprgYZgtwLNL5y4jKAGFkV7718GQA@mail.gmail.com>
References: <54FABEA1.3040008@opencsw.org>
	<CALtRa-7AHi2rODoCmSxXoqprgYZgtwLNL5y4jKAGFkV7718GQA@mail.gmail.com>
Message-ID: <54FACB49.7000609@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-03-07 9:02 GMT+00:00 Riccardo Mottola<rmottola at opencsw.org>:
>> >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>
	<CALtRa-7AHi2rODoCmSxXoqprgYZgtwLNL5y4jKAGFkV7718GQA@mail.gmail.com>
	<54FACB49.7000609@opencsw.org>
Message-ID: <CALtRa-5VjcZDhnjSv4AE0XUR63AX_mJrq4AqAqGfLwU4jXq2hg@mail.gmail.com>

2015-03-07 9:56 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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: <CALtRa-5VjcZDhnjSv4AE0XUR63AX_mJrq4AqAqGfLwU4jXq2hg@mail.gmail.com>
References: <54FABEA1.3040008@opencsw.org>	<CALtRa-7AHi2rODoCmSxXoqprgYZgtwLNL5y4jKAGFkV7718GQA@mail.gmail.com>	<54FACB49.7000609@opencsw.org>
	<CALtRa-5VjcZDhnjSv4AE0XUR63AX_mJrq4AqAqGfLwU4jXq2hg@mail.gmail.com>
Message-ID: <54FAD393.9060706@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-03-07 9:56 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
>> 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>
	<CALtRa-7AHi2rODoCmSxXoqprgYZgtwLNL5y4jKAGFkV7718GQA@mail.gmail.com>
	<54FACB49.7000609@opencsw.org>
	<CALtRa-5VjcZDhnjSv4AE0XUR63AX_mJrq4AqAqGfLwU4jXq2hg@mail.gmail.com>
	<54FAD393.9060706@opencsw.org>
Message-ID: <CALtRa-6HVW=BG3+YpHOKdi2hC1m+cSZZYscLq6+8o_uB7=NZyQ@mail.gmail.com>

2015-03-07 10:31 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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: <CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>

2015-03-07 9:05 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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: <CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>
References: <54FABF4A.50701@opencsw.org>
	<CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>
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: <CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>
References: <54FABF4A.50701@opencsw.org>
	<CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>
Message-ID: <54FB37ED.60204@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-03-07 9:05 GMT+00:00 Riccardo Mottola<rmottola at opencsw.org>:
>> >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>
	<CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>
	<54FAF1EB.1080708@opencsw.org>
Message-ID: <93778141-314A-4EFB-8631-1045E67642C9@opencsw.org>

Hi,

> Am 07.03.2015 um 13:41 schrieb Laurent Blume <laurent at 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 .

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150307/cb76415f/attachment.p7s>

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>
	<CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>
	<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 <rmottola at opencsw.org>:
> 
> Maciej (Matchek) Blizi?ski wrote:
>> 2015-03-07 9:05 GMT+00:00 Riccardo Mottola<rmottola at opencsw.org>:
>>> >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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150307/812b4918/attachment.p7s>

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>	<CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>	<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>
	<CALtRa-7vYLSm6PtVqXB78okMtoaLiSGUZjZSgraMZgnR3--wGA@mail.gmail.com>
	<54FB37ED.60204@opencsw.org>
	<475E0804-C60F-4686-9F16-CCD2132E6169@opencsw.org>
	<54FB5BF3.8040906@opencsw.org>
Message-ID: <DB3E8F21-1476-4610-B94A-4088D79675C6@opencsw.org>

Hi Riccardo,

> Am 07.03.2015 um 21:13 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150307/ffa96d02/attachment.p7s>

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<<<</libffi.so=../libffi.so.6.0.4

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/).

Laurent


 

From dam at opencsw.org  Sun Mar  8 12:14:16 2015
From: dam at opencsw.org (Dagobert Michelsen)
Date: Sun, 8 Mar 2015 12:14:16 +0100
Subject: missing libffi.so master link
In-Reply-To: <54FC2E5C.6020902@opencsw.org>
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 <laurent at 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<<<</libffi.so=../libffi.so.6.0.4
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150308/311465ef/attachment.p7s>

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: <CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>

2015-03-08 11:31 GMT+00:00 Laurent Blume <laurent at opencsw.org>:
> 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: <CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org>
	<54FC2E5C.6020902@opencsw.org>	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>	<54FC3302.6000307@opencsw.org>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
Message-ID: <54FC4D62.7000304@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-03-08 11:31 GMT+00:00 Laurent Blume <laurent at opencsw.org>:
>> 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: <CALtRa-5UmHULky7QPgupB8T61VyRmqcN3n-2zDSYxo8=LRprCg@mail.gmail.com>

2015-03-08 13:27 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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: <F4984FCA-093C-4C60-A55E-1336C6153550@opencsw.org>

Hi Riccardo,

> Am 08.03.2015 um 14:27 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150308/2d5d8d3f/attachment.p7s>

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: <F4984FCA-093C-4C60-A55E-1336C6153550@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>
	<F4984FCA-093C-4C60-A55E-1336C6153550@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: <CALtRa-6UamBAocoZknqG3mPkMn-thsJ081sqrNmt1JLJx2x5yg@mail.gmail.com>
References: <CAGUt3y7gQzdik=ZQf1g8rKwPHUqA_p8NHQwxz-gt+yk66zshvw@mail.gmail.com>
	<78E7C1BB-2F2B-48D0-9FFF-BFA48321BE45@opencsw.org>
	<CADL=-c11vXP8u126HVDk050vybagaJONYy2rA-hLLBkzTqNg+g@mail.gmail.com>
	<CALtRa-6UamBAocoZknqG3mPkMn-thsJ081sqrNmt1JLJx2x5yg@mail.gmail.com>
Message-ID: <CALtRa-6vYJNYrLv+PR+F-+HRKRic_xZ3YmMGWL5dKDgEbAMWMg@mail.gmail.com>

2015-03-05 1:41 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
>
> 2015-03-04 9:21 GMT+00:00 Nils Ludvig Brandtz?g <ludvigb at gmail.com>:
> > 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>	<F4984FCA-093C-4C60-A55E-1336C6153550@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>
	<F4984FCA-093C-4C60-A55E-1336C6153550@opencsw.org>
	<54FC5704.8070806@opencsw.org> <54FCAA63.8020801@opencsw.org>
Message-ID: <CALtRa-5XDES-LTK2dfkY4RJcKGFC88FDwQSkXmuWNz5wvpV=uQ@mail.gmail.com>

2015-03-08 20:00 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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>	<F4984FCA-093C-4C60-A55E-1336C6153550@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: <CALtRa-5XDES-LTK2dfkY4RJcKGFC88FDwQSkXmuWNz5wvpV=uQ@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org>
	<54FC2E5C.6020902@opencsw.org>	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>	<54FC3302.6000307@opencsw.org>
	<54FC4E2D.4090903@opencsw.org>	<F4984FCA-093C-4C60-A55E-1336C6153550@opencsw.org>	<54FC5704.8070806@opencsw.org>
	<54FCAA63.8020801@opencsw.org>
	<CALtRa-5XDES-LTK2dfkY4RJcKGFC88FDwQSkXmuWNz5wvpV=uQ@mail.gmail.com>
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>	<F4984FCA-093C-4C60-A55E-1336C6153550@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>
	<F4984FCA-093C-4C60-A55E-1336C6153550@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 <rmottola at 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.

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150309/8183e766/attachment.p7s>

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>	<F4984FCA-093C-4C60-A55E-1336C6153550@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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150309/5faf8841/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: confout.Z
Type: application/x-compress
Size: 5889 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150309/5faf8841/attachment-0003.bin>

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>	<F4984FCA-093C-4C60-A55E-1336C6153550@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>
	<F4984FCA-093C-4C60-A55E-1336C6153550@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: <C4ED6614-25F5-4726-9062-1CDD63BC69E6@opencsw.org>

Hi Riccardo,

> Am 12.03.2015 um 14:28 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150312/d758be4c/attachment.p7s>

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: <C4ED6614-25F5-4726-9062-1CDD63BC69E6@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>	<F4984FCA-093C-4C60-A55E-1336C6153550@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>
	<C4ED6614-25F5-4726-9062-1CDD63BC69E6@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>	<F4984FCA-093C-4C60-A55E-1336C6153550@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>	<C4ED6614-25F5-4726-9062-1CDD63BC69E6@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: <CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org>
	<54FC2E5C.6020902@opencsw.org>	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>	<54FC3302.6000307@opencsw.org>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
Message-ID: <550745B1.903@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-03-08 11:31 GMT+00:00 Laurent Blume <laurent at opencsw.org>:
>> 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: <CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org>
	<54FC2E5C.6020902@opencsw.org>	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>	<54FC3302.6000307@opencsw.org>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
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>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
	<550745B1.903@opencsw.org>
Message-ID: <CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>

2015-03-16 21:05 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:

> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150317/0a5a8333/attachment.html>

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: <CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org>
	<54FC2E5C.6020902@opencsw.org>	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>	<54FC3302.6000307@opencsw.org>	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>	<550745B1.903@opencsw.org>
	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
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: <CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org>
	<54FC2E5C.6020902@opencsw.org>	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>	<54FC3302.6000307@opencsw.org>	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>	<550745B1.903@opencsw.org>
	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
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>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
	<550745B1.903@opencsw.org>
	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
	<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 <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150317/bef08a1b/attachment-0001.p7s>

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>	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>	<550745B1.903@opencsw.org>	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>	<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 <rmottola at opencsw.org>:
>>
>> 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: <bf3dab8a372d.55081687@contac-dt.de>
References: <55080E51.7070006@opencsw.org> <bf3d81e974f0.5508164b@contac-dt.de>
	<bf3dab8a372d.55081687@contac-dt.de>
Message-ID: <bf3de8ad6726.550824b4@contac-dt.de>

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  <rmottola at 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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150317/ecaa5631/attachment.html>

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>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
	<550745B1.903@opencsw.org>
	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
	<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 <rmottola at opencsw.org>:
> 
> Dagobert Michelsen wrote:
>>> Am 17.03.2015 um 10:41 schrieb Riccardo Mottola <rmottola at opencsw.org>:
>>> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150317/a16b26d0/attachment.p7s>

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: <bf3de8ad6726.550824b4@contac-dt.de>
References: <55080E51.7070006@opencsw.org>
	<bf3d81e974f0.5508164b@contac-dt.de>	<bf3dab8a372d.55081687@contac-dt.de>
	<bf3de8ad6726.550824b4@contac-dt.de>
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>	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>	<550745B1.903@opencsw.org>	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>	<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> <bf3d81e974f0.5508164b@contac-dt.de>
	<bf3dab8a372d.55081687@contac-dt.de>
	<bf3de8ad6726.550824b4@contac-dt.de> <55092E99.1040202@opencsw.org>
Message-ID: <AC066D43-30F3-458A-81ED-D3AAEA47974A@opencsw.org>

Hi Riccardo,

> Am 18.03.2015 um 08:51 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150318/815792bd/attachment-0001.p7s>

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>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
	<550745B1.903@opencsw.org>
	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
	<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 <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150318/1873138b/attachment.p7s>

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: <F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>

Hi Riccardo,

> Am 18.03.2015 um 08:55 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150318/5126249c/attachment.p7s>

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: <F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>
References: <55092F5F.6010007@opencsw.org>
	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@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 <rmottola at opencsw.org>:
> > 
> > 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>
	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>
	<20150318092934.GA4152@quince>
Message-ID: <E8A1D25E-38CD-4E4A-BF63-13828A7D1203@opencsw.org>

Hi,

> Am 18.03.2015 um 10:29 schrieb Maciej Blizi?ski <maciej at opencsw.org>:
> 
> On Wed, Mar 18, 2015 at 10:06:07AM +0100, Dagobert Michelsen wrote:
>>> Am 18.03.2015 um 08:55 schrieb Riccardo Mottola <rmottola at opencsw.org>:
>>> 
>>> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150318/f25db623/attachment.p7s>

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: <E8A1D25E-38CD-4E4A-BF63-13828A7D1203@opencsw.org>
References: <55092F5F.6010007@opencsw.org>
	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>
	<20150318092934.GA4152@quince>
	<E8A1D25E-38CD-4E4A-BF63-13828A7D1203@opencsw.org>
Message-ID: <CALtRa-7F_WyTweCDsDhdWPmt58-SFCyMceAP=t0T-C93cC_D6A@mail.gmail.com>

2015-03-18 9:39 GMT+00:00 Dagobert Michelsen <dam at opencsw.org>:
> 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>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
	<550745B1.903@opencsw.org>
	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
	<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: <CALtRa-5Vu+Y46j4Z320Ly7OUToiK4emyVQ9K_7ci39uvmDSjtQ@mail.gmail.com>

2015-03-18 8:41 GMT+00:00 Dagobert Michelsen <dam at opencsw.org>:
> 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: <CALtRa-5Vu+Y46j4Z320Ly7OUToiK4emyVQ9K_7ci39uvmDSjtQ@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org> <54FC2E5C.6020902@opencsw.org>
	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>
	<54FC3302.6000307@opencsw.org>
	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>
	<550745B1.903@opencsw.org>
	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>
	<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>
	<CALtRa-5Vu+Y46j4Z320Ly7OUToiK4emyVQ9K_7ci39uvmDSjtQ@mail.gmail.com>
Message-ID: <CALtRa-6GGeB164abN5zXZRYQuwh-bs6L3tNnY4aV3XfJW8Jvpw@mail.gmail.com>

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: <CALtRa-5Vu+Y46j4Z320Ly7OUToiK4emyVQ9K_7ci39uvmDSjtQ@mail.gmail.com>
References: <54FC17F7.5020403@opencsw.org>
	<54FC2E5C.6020902@opencsw.org>	<22C1774D-FFC4-4131-B388-8FFB6C60DBEA@opencsw.org>	<54FC3302.6000307@opencsw.org>	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>	<550745B1.903@opencsw.org>	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>	<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>
	<CALtRa-5Vu+Y46j4Z320Ly7OUToiK4emyVQ9K_7ci39uvmDSjtQ@mail.gmail.com>
Message-ID: <5509CFB8.9000804@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-03-18 8:41 GMT+00:00 Dagobert Michelsen <dam at opencsw.org>:
>> 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>	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@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>	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>	<550745B1.903@opencsw.org>	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>	<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>	<CALtRa-5Vu+Y46j4Z320Ly7OUToiK4emyVQ9K_7ci39uvmDSjtQ@mail.gmail.com>
	<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>
	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>
	<20150318092934.GA4152@quince> <5509CFC4.4090609@opencsw.org>
Message-ID: <CALtRa-7K4LNmjEaqNryDycz9Y7ejk7GyHJd3jvk9tmr5pwrCOA@mail.gmail.com>

2015-03-18 19:19 GMT+00:00 Laurent Blume <laurent at opencsw.org>:
> 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: <CALtRa-7K4LNmjEaqNryDycz9Y7ejk7GyHJd3jvk9tmr5pwrCOA@mail.gmail.com>
References: <55092F5F.6010007@opencsw.org>	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>	<20150318092934.GA4152@quince>
	<5509CFC4.4090609@opencsw.org>
	<CALtRa-7K4LNmjEaqNryDycz9Y7ejk7GyHJd3jvk9tmr5pwrCOA@mail.gmail.com>
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 <laurent at opencsw.org>:
>> 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>
	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>
	<20150318092934.GA4152@quince> <5509CFC4.4090609@opencsw.org>
	<CALtRa-7K4LNmjEaqNryDycz9Y7ejk7GyHJd3jvk9tmr5pwrCOA@mail.gmail.com>
	<5509DC7D.6080707@opencsw.org>
Message-ID: <CALtRa-7A03pDHcF68rESPiHB+Hi7tSvhDUDADXiz6Av33_uNVg@mail.gmail.com>

2015-03-18 20:13 GMT+00:00 Laurent Blume <laurent at opencsw.org>:
> 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: <CALtRa-7A03pDHcF68rESPiHB+Hi7tSvhDUDADXiz6Av33_uNVg@mail.gmail.com>
References: <55092F5F.6010007@opencsw.org>	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>	<20150318092934.GA4152@quince>
	<5509CFC4.4090609@opencsw.org>	<CALtRa-7K4LNmjEaqNryDycz9Y7ejk7GyHJd3jvk9tmr5pwrCOA@mail.gmail.com>	<5509DC7D.6080707@opencsw.org>
	<CALtRa-7A03pDHcF68rESPiHB+Hi7tSvhDUDADXiz6Av33_uNVg@mail.gmail.com>
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: <CALtRa-7F_WyTweCDsDhdWPmt58-SFCyMceAP=t0T-C93cC_D6A@mail.gmail.com>
References: <55092F5F.6010007@opencsw.org>	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>	<20150318092934.GA4152@quince>	<E8A1D25E-38CD-4E4A-BF63-13828A7D1203@opencsw.org>
	<CALtRa-7F_WyTweCDsDhdWPmt58-SFCyMceAP=t0T-C93cC_D6A@mail.gmail.com>
Message-ID: <550B0F64.90706@opencsw.org>

Hi,

Maciej (Matchek) Blizi?ski wrote:
> 2015-03-18 9:39 GMT+00:00 Dagobert Michelsen <dam at opencsw.org>:
>> 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>	<CALtRa-748WpFoYmS6ASSM87XfGu-S5Ap+iBGCM8GtL_o053xxA@mail.gmail.com>	<550745B1.903@opencsw.org>	<CALtRa-48gLCK__mCJ5fAhoEguUqmdShG0VjedKaAAA0PWYEGTQ@mail.gmail.com>	<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>	<CALtRa-5Vu+Y46j4Z320Ly7OUToiK4emyVQ9K_7ci39uvmDSjtQ@mail.gmail.com>	<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: <CALtRa-6wMqbOND0nT0P0EJWxngTSmLo=3Czqk=QPhxFdbrbTiA@mail.gmail.com>

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150320/0224185b/attachment.html>

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: <bf3dc1152a0d.54f97c1f@contac-dt.de>
References: <bf3dfc123924.54f967bb@contac-dt.de>
	<bf3db9d761d.54f96835@contac-dt.de>
	<bf3de4fa70a1.54f96872@contac-dt.de>
	<bf3d92b8223f.54f968b1@contac-dt.de>
	<bf3d97165304.54f968f0@contac-dt.de>
	<bf3dc4364795.54f9692c@contac-dt.de>
	<bf3d9bdd5450.54f96968@contac-dt.de>
	<bf3dece72ae5.54f969a7@contac-dt.de>
	<bf3db83d5339.54f969e4@contac-dt.de>
	<bf3dafcb257.54f96a20@contac-dt.de>
	<bf3da416f04.54f96a98@contac-dt.de>
	<bf3dc5813f0d.54f96c7b@contac-dt.de>
	<bf3dbfb66965.54f96cb8@contac-dt.de>
	<bf3d90de751c.54f96cf7@contac-dt.de>
	<bf3d9fe31514.54f96d33@contac-dt.de>
	<bf3d81bda11.54f96dae@contac-dt.de>
	<bf3dfb3b78e7.54f96dea@contac-dt.de>
	<bf3dc1152a0d.54f97c1f@contac-dt.de>
Message-ID: <CALtRa-6K=X+EeaL6MYU6n9_XvH8GgmXtG+WzYM6Tu2tpW=2Ghw@mail.gmail.com>

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150320/b8a32465/attachment.html>

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 <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150321/c024617c/attachment.p7s>

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: <DC71E76E-E592-43CE-B2E0-BA5696D62395@opencsw.org>

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150321/021d61a7/attachment.p7s>

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 <something>"
In-Reply-To: <54D74912.8050207@opencsw.org>
References: <CALtRa-7qqoKuxbZAgKJRxXhcwaJDeMJwiBFPjnzofw88_Aydsg@mail.gmail.com>
	<54D74912.8050207@opencsw.org>
Message-ID: <CALtRa-49te0s-8vcJigevVbtmy7pufstVOZD-QJBg+nam2gf9g@mail.gmail.com>

2015-02-08 11:31 GMT+00:00 Riccardo Mottola <rmottola at opencsw.org>:
> 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/<foo>), 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 <foo>"
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 <something>"
In-Reply-To: <CALtRa-49te0s-8vcJigevVbtmy7pufstVOZD-QJBg+nam2gf9g@mail.gmail.com>
References: <CALtRa-7qqoKuxbZAgKJRxXhcwaJDeMJwiBFPjnzofw88_Aydsg@mail.gmail.com>
	<54D74912.8050207@opencsw.org>
	<CALtRa-49te0s-8vcJigevVbtmy7pufstVOZD-QJBg+nam2gf9g@mail.gmail.com>
Message-ID: <CALtRa-5dipxY38ZNeL_8LBj50O_UH7+z-FsoxL4uArakqLtj0g@mail.gmail.com>

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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150322/9b396585/attachment.html>

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 <something>"
In-Reply-To: <CALtRa-5dipxY38ZNeL_8LBj50O_UH7+z-FsoxL4uArakqLtj0g@mail.gmail.com>
	("Maciej (Matchek) =?utf-8?Q?Blizi=C5=84ski=22's?= message of "Sun,
	22 Mar 2015 16:35:46 +0000")
References: <CALtRa-7qqoKuxbZAgKJRxXhcwaJDeMJwiBFPjnzofw88_Aydsg@mail.gmail.com>
	<54D74912.8050207@opencsw.org>
	<CALtRa-49te0s-8vcJigevVbtmy7pufstVOZD-QJBg+nam2gf9g@mail.gmail.com>
	<CALtRa-5dipxY38ZNeL_8LBj50O_UH7+z-FsoxL4uArakqLtj0g@mail.gmail.com>
Message-ID: <x6y4mpaqhb.fsf@opencsw.org>

"Maciej (Matchek) Blizi?ski" <maciej at opencsw.org> 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:

<ork/solaris9-sparc/build-isa-sparcv9/icu/source/test/letest/letest
ld.so.1: letest: fatal: libicule.so.54: open failed: No such file or 
directory
ld.so.1: letest: fatal: relocation error: file 
work/solaris9-sparc/build-isa-sparcv9/icu/source/test/letest/letest: 
symbol __1cGicu_54UOpenTypeLayoutEngineMlanguageTags_: referenced symbol 
not found
Killed

The error happens both in v8 and v9 versions.

Why would this happen (and why on solaris 9 and not 10)?

If I grep for it, I get:
Binary file 
work/solaris9-sparc/build-isa-sparcv9/icu/source/lib/libicule.so matches
(I wonder where the source of it is actually)

perhaps some -L -R magic that is missing or anyway different in solaris 10?

Riccardo


From laurent at opencsw.org  Sun Mar 22 19:37:22 2015
From: laurent at opencsw.org (Laurent Blume)
Date: Sun, 22 Mar 2015 19:37:22 +0100
Subject: libicu on solaris 9s
In-Reply-To: <550F1928.6030006@opencsw.org>
References: <550F1928.6030006@opencsw.org>
Message-ID: <550F0BE2.6050500@opencsw.org>

Le 2015/03/22 20:34 +0100, Riccardo Mottola a ?crit:
> <ork/solaris9-sparc/build-isa-sparcv9/icu/source/test/letest/letest
> 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: <CALtRa-5CNgCXSywp0PMuV_6jwJcp0DdSWJZb7f6Xkyd7cq_QfA@mail.gmail.com>
References: <CALtRa-73TQSA-+M47o2a9aZEsG9T9J54+p03eUNo5b1yOSXeMw@mail.gmail.com>
	<CABY0g1W7JNE1RwZ1tPtHN4FF3iaZtR2U3S864gJusbmj=rO85A@mail.gmail.com>
	<CALtRa-5x5geKCHQD7HXNFrAiXiYGX=ePt3kMAaH7M7nPPs4u+w@mail.gmail.com>
	<CALtRa-5CNgCXSywp0PMuV_6jwJcp0DdSWJZb7f6Xkyd7cq_QfA@mail.gmail.com>
Message-ID: <CALtRa-6kFGUb4=Dgq2SSrvFn=xCvHNDeUR9hMfS-nS3rfgTPLg@mail.gmail.com>

2015-01-04 23:40 GMT+00:00 Maciej (Matchek) Blizi?ski <maciej at opencsw.org>:
> 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 <wilbury at opencsw.org>


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 <wilbury at opencsw.org>


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: <C089D64D-FB31-4466-BFD1-FF222E08ECDC@opencsw.org>

Hi Ihsan,

> Am 24.03.2015 um 09:38 schrieb Ihsan Dogan <ihsan at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150324/ba3788b5/attachment.p7s>

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 <wilbury at opencsw.org>


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>
	<F90C428F-5E98-415A-8175-01F1A5F6F8EB@opencsw.org>
	<20150318092934.GA4152@quince>
	<E8A1D25E-38CD-4E4A-BF63-13828A7D1203@opencsw.org>
	<CALtRa-7F_WyTweCDsDhdWPmt58-SFCyMceAP=t0T-C93cC_D6A@mail.gmail.com>
	<550B0F64.90706@opencsw.org>
Message-ID: <B2E88BA4-A2C5-4CBD-AE9A-D8A4B9D8A8B8@opencsw.org>

Hi Riccardo,

> Am 19.03.2015 um 19:03 schrieb Riccardo Mottola <rmottola at opencsw.org>:
> Maciej (Matchek) Blizi?ski wrote:
>> 2015-03-18 9:39 GMT+00:00 Dagobert Michelsen <dam at opencsw.org>:
>>> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150324/cf51bc9f/attachment.p7s>

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 <rmottola at opencsw.org>:
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150324/5f7a4800/attachment.p7s>

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: <CALtRa-6mjP5npCBJkR0KOpMnRGNrw1kiyR-7TGOx8YSPzXDgXw@mail.gmail.com>

http://bazel.io/

Linux, OS X
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150324/5522ec64/attachment.html>

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: <CALtRa-6mjP5npCBJkR0KOpMnRGNrw1kiyR-7TGOx8YSPzXDgXw@mail.gmail.com>
References: <CALtRa-6mjP5npCBJkR0KOpMnRGNrw1kiyR-7TGOx8YSPzXDgXw@mail.gmail.com>
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 <maciej at opencsw.org>:
> 
> 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: <CALtRa-6mjP5npCBJkR0KOpMnRGNrw1kiyR-7TGOx8YSPzXDgXw@mail.gmail.com>
	<2063B79F-26C9-43B0-A408-C121A9CA9196@opencsw.org>
Message-ID: <CALtRa-5wukhxxVdKaB2Kzd_ywwkjmO_riS8FYinZ74_Pw0dqyA@mail.gmail.com>

2015-03-24 16:15 GMT+00:00 slowfranklin <slowfranklin at opencsw.org>:
> 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: <x6pp7vbnyc.fsf@opencsw.org>

Riccardo Mottola <rmottola at opencsw.org> 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 <rmottola at opencsw.org>:
> 
> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150327/ed7eeaa6/attachment.p7s>

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: <C089D64D-FB31-4466-BFD1-FF222E08ECDC@opencsw.org>
References: <20150323104851.GA77282@dogan.ch> <550FF075.3050605@opencsw.org>
	<20150323110117.GB77282@dogan.ch> <55100B63.7010702@opencsw.org>
	<20150324083858.GB5267@dogan.ch>
	<C089D64D-FB31-4466-BFD1-FF222E08ECDC@opencsw.org>
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 <rmottola at opencsw.org>:
>>> 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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150328/1422cebd/attachment-0001.p7s>

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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>

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 <module>
     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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
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 <module>
>     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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<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 <module>
>>      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 
<http://wiki.opencsw.org/checkpkg-error-tags#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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150329/2b336c0f/attachment.html>

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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<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 <module>
> >>     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
> <http://wiki.opencsw.org/checkpkg-error-tags#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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>	<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 
<http://wiki.opencsw.org/checkpkg-error-tags#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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<20150329171000.GA5734@cotton.home.blizinski.pl>
	<55185956.1000108@opencsw.org> <20150329203329.GB15776@quince>
	<551A490D.8060003@opencsw.org>
Message-ID: <x6h9t1ax3k.fsf@opencsw.org>

Riccardo Mottola <rmottola at opencsw.org> 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: <x6h9t1ax3k.fsf@opencsw.org>
References: <b957aedbb1077f8557060ec300623b2a@fuchur.local>	<20150329171000.GA5734@cotton.home.blizinski.pl>	<55185956.1000108@opencsw.org>
	<20150329203329.GB15776@quince>	<551A490D.8060003@opencsw.org>
	<x6h9t1ax3k.fsf@opencsw.org>
Message-ID: <551AFF35.4070306@opencsw.org>

Hi,

Peter FELECAN wrote:
> Riccardo Mottola <rmottola at opencsw.org> 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: <b957aedbb1077f8557060ec300623b2a@fuchur.local>
	<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: <http://lists.opencsw.org/pipermail/maintainers/attachments/20150331/bbbb1948/attachment.asc>