[Fink-devel] gcc45-10.4.info fix

[Jack Howarth]

  Could someone check in the following change to
gcc45-10.4.info in unstable?

Index: gcc45-10.4.info
===
RCS file: 
/cvsroot/fink/dists/10.4/unstable/main/finkinfo/languages/gcc45-10.4.info,v
retrieving revision 1.2
diff -r1.2 gcc45-10.4.info
19c19
< BuildDepends: gmp (>= 4.3.2-1), libmpfr1 (>= 2.4.2-2), libiconv-dev, 
gettext-tools, libgettext8-dev, libmpc2 (>= 0.8.1-1),  xcode (>= 3.1.2), fink 
(>= 0.27.2)
---
> BuildDepends: gmp (>= 4.3.2-1), libmpfr1 (>= 2.4.2-2), libiconv-dev, 
> gettext-tools, libgettext8-dev, libmpc2 (>= 0.8.1-1),  xcode (>= 2.5), fink 
> (>= 0.27.2)
177c177
<   Depends: gmp-shlibs (>= 4.3.2-1), libgmpxx-shlibs (>= 4.3.2-1), 
libmpfr1-shlibs (>= 2.4.2-2), %N-shlibs (= %v-%r), libiconv, 
libgettext8-shlibs, libmpc2-shlibs (>= 0.8.1-1), xcode (>= 3.1.2)
---
>   Depends: gmp-shlibs (>= 4.3.2-1), libgmpxx-shlibs (>= 4.3.2-1), 
> libmpfr1-shlibs (>= 2.4.2-2), %N-shlibs (= %v-%r), libiconv, 
> libgettext8-shlibs, libmpc2-shlibs (>= 0.8.1-1), xcode (>= 2.5)

I missed that when trying to synchronize the changes across the various gcc45
variants. Thanks in advance.
  Jack

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] scientificpython-py vs obsolete scipy-core-py

[Jack Howarth]

Kurt,
   I noticed while updating relax-py for fink unstable
that scientificpython-py currently depends on the
obsolete scipy-core-py package. Could you update the
scientificpython-py package to depend on numpy-py instead?
Thanks in advance as this will allow -m builds.
   Jack

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] python variant convention

[Jack Howarth]

   I noticed a lot of packages in unstable still contain lines
like...

Distribution: (%type_pkg[python] = 23) 10.4, (%type_pkg[python] = 24) 10.4, 
(%type_pkg[python] = 24) 10.5

and support python variants other than 2.5 and 2.6. Hasn't the
convention in fink unstable been changed such that only py25 and py26
variants are to be supported? If so, perhaps the core maintainers
can go through unstable and correct these.
Jack
ps A short list of the current offending packages include...

unstable/crypto/finkinfo/gmailfs-py.info:Type: python (2.4 2.5)
unstable/crypto/finkinfo/gnupg-interface-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/libapache2-mod-python-py-ssl.info:Type: python (2.3 
2.4), -ssl -ssl
unstable/crypto/finkinfo/libgmail-py.info:Type: python (2.3 2.4 2.5)
unstable/crypto/finkinfo/nevow-py.info:Type: python (2.3 2.4)
unstable/crypto/finkinfo/paramiko-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/crypto/finkinfo/pycrypto-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/crypto/finkinfo/python-tlslite-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted-py.info:Type: python (2.3 2.4)
unstable/crypto/finkinfo/twisted2-conch-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-flow-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-lore-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-mail-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-names-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-news-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-pair-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-runner-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-web-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-web2-py.info:Type: python (2.4 2.5 2.6)
unstable/crypto/finkinfo/twisted2-words-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/database/elixir-py.info:Type: python (2.4 2.5)
unstable/main/finkinfo/database/mysql-python-py.info:Type: python(2.4 2.5 2.6)
unstable/main/finkinfo/database/postgresql-python-py.info:Type: python(2.3 2.4 
2.5 2.6)
unstable/main/finkinfo/database/postgresql83-python-py.info:Type: python(2.3 
2.4 2.5 2.6)
unstable/main/finkinfo/database/psycopg2-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/database/pysqlite-py.info:Type: python(2.3 2.4 2.5)
unstable/main/finkinfo/database/pysqlite2-py.info:Type: python(2.3 2.4 2.5 2.6)
unstable/main/finkinfo/database/sqlalchemy-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/devel/bzr-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/devel/codeville-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/devel/importchecker-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/devel/mercurial-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/devel/mpi4py-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/devel/psyco-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/devel/pychecker-py.info:Type: python(2.3 2.4 2.5 2.6)
unstable/main/finkinfo/devel/pyrex-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/devel/svn-swig-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/devel/tailor-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/games/pygame-py.info:Type: python (2.3 2.4 2.5)
unstable/main/finkinfo/gnome/gnome-menus2-py-2.20.3.info:Type: python (2.3 2.4)
unstable/main/finkinfo/gnome/gnome-python2-py-2.20.1.info:Type: python (2.3 2.4)
unstable/main/finkinfo/gnome/pygobject2-py-2.15.4.info:Type: python (2.3 2.4 
2.5)
unstable/main/finkinfo/gnome/pygoocanvas-py24.info:Type: python 2.4
unstable/main/finkinfo/gnome/pygtk2-gtk-py-2.12.1.info:Type: python (2.3 2.4)
unstable/main/finkinfo/gnome/pygtk2-py.info:Type: python (2.3 2.4 2.5), nosource
unstable/main/finkinfo/gnome/pygtksourceview2-py-2.0.0.info:Type: python (2.3 
2.4)
unstable/main/finkinfo/gnome/pyorbit2-py-2.14.3.info:Type: python (2.4 2.5)
unstable/main/finkinfo/gnome/vte-py24.info:Type: python 2.4
unstable/main/finkinfo/graphics/pdflib-py.info:Type: python (2.4 2.5)
unstable/main/finkinfo/graphics/pil-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/graphics/pycairo-py24.info:Type: python 2.4
unstable/main/finkinfo/graphics/reportlab-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/languages/f2py-py.info:Type: python (2.3 2.4)
unstable/main/finkinfo/languages/ipython-py.info:Type: python(2.3 2.4 2.5 2.6)
unstable/main/finkinfo/languages/pyfort-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/languages/pyqt-py.info:Type: python (2.3 2.4 2.5 2.6)
unstable/main/finkinfo/languages/pyqt4-mac-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/languages/pyqt4-py.info:Type: python (2.4 2.5 2.6)
unstable/main/finkinfo/languages/pyslang-py.info:Type: python (2.3 2.4

Re: [Fink-devel] python variant convention

[Jack Howarth]

Dave,
   Perhaps I was confused by the proposed changes for the fink 10.5 release...

http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5

My reading of that was that py23 variants should be depreciated.
Jack

On Sat, Jun 26, 2010 at 09:33:39AM -0600, David R. Morrison wrote:
> Jack,
> 
> Actually, leaving the old variants of python in place is perfectly OK.  There 
> may be people still using old versions of python (on 10.4 or 10.5) and 
> leaving these variants for them is fine.  Of course, if a maintainer stops 
> being able to test new versions of the package with old versions of python, 
> the she or he should probably stop supporting the old versions.  Even in that 
> case, though, it is a courtesy to add something like foo-py24.info to fink 
> providing the old version of the package (in an obsolete variant) 
> indefinitely into the future.
> 
>   -- Dave
> 
> 

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] gcc4x/cloog/ppl

[Jack Howarth]

  I would be interested in the general consensus on
the following. A new recommended update to ppl,
version 0.11, was released this week. Currently
cloog won't build against this due to a version
check which will soon be adjusted to allow this.
However, allowing cloog to build with the same
soversion against either ppl-0.10.x or ppl-0.11
will introduce shared library coherency problems
with the gcc4x packages that build against cloog
and ppl.
   My first instinct was to create a conflicting
ppl2 package for ppl v0.11 which has ppl2-shlibs
split-off which can co-exist with ppl2-shlibs
and then rebuild cloog against ppl2. I immediately
discovered however that legacy builds of gcc4x
would end up indirectly linked to different ppl
versions...

[MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L f951
f951:
/sw/lib/libintl.8.dylib (compatibility version 9.0.0, current version 
9.2.0)
/sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 
7.0.0)
/sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current version 
1.0.0)
/sw/lib/libppl_c.2.dylib (compatibility version 4.0.0, current version 
4.0.0)
/sw/lib/libppl.7.dylib (compatibility version 9.0.0, current version 
9.0.0)
/sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current version 
6.2.0)
/sw/lib/libmpc.2.dylib (compatibility version 3.0.0, current version 
3.0.0)
/sw/lib/libmpfr.1.dylib (compatibility version 4.0.0, current version 
4.2.0)
/sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 
9.2.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.3)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
438.0.0)
/sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 125.2.0)

[MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L 
/sw/lib/libcloog.0.dylib
/sw/lib/libcloog.0.dylib:
/sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current version 
1.0.0)
/sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 
9.2.0)
/sw/lib/libppl_c.4.dylib (compatibility version 5.0.0, current version 
5.0.0)
/sw/lib/libppl.9.dylib (compatibility version 10.0.0, current version 
10.0.0)
/sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current version 
6.2.0)

I am trying to convince upstream to take the slightly non-conventional
approach of a cloog-0.16 release which requires ppl-0.11 or later to build
and contains a soversion bump. If this is rejected, we will be faced with
a less than optimal upgrade path as all gcc4x packages built against
cloog/ppl will have to be forcibly upgraded to build against ppl-0.11 and
cloog built with the same.
   Any advice on this is welcome. My main concern is that if the soversion bump
is rejected, we will also have to worry about stray cloog.0.dylib's in 
/usr/local/lib, etc
built against an older ppl.
 Jack

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc4x/cloog/ppl

[Jack Howarth]

On Fri, Aug 06, 2010 at 05:35:55PM +0200, Jean-François Mertens wrote:
>
> On 06 Aug 2010, at 17:32, Jean-François Mertens wrote:
>
>> As long a cloog's own install_name doesn't change, I see in principle 
>> no problem in
>> creating a new ppl pkg for the new version (since there the install  
>> name does change),
>> and to upgrade (independently, ie, whenever you want) cloog and one or 
>> more gccxy pkgs
>> to use the new ppl (and/or) the updated cloog.
>> I.e., cloog and gccxy using diferent ppl's should not be a problem per 
>> se
>> (as long as you can prevent cloog's flags for ppl to come before gcc's 
>> own flags in the
>> build of gcc; but that's at worst a flag-ordering problem).
>
> More explicity, for cloog it can be a plain version update, and things  
> that linked to
> the old version should continue linking well with the new, w/o  
> rebuilding.
>
> JF

JF,
  Apparently both Debian and Fedora have been building gcc with -ldl
and thus don't have explicit linkages in the gcc binaries to libppl,
libppl_c and libcloog. However they still end up with the same issue.
If you build gcc with a libcloog and ppl 0.10.2, the ppl headers
(and interfaces) will be from ppl 0.10.2 whereas if you later upgrade
cloog to a version built against ppl 0.11 your will get a header 
mismatch. The graphite support in gcc will have been built against
the ppl headers from a different soversion than those used to build
cloog.
   The gcc developers seem to agree that gcc needs a version check
for the ppl in use. However I would argue that this merits a new
cloog call to properly do it (which in turn allows for a valid
soversion bump in cloog). In the extreme, both gcc and cloog could
embed the version of ppl used to build them. When graphite is used
in gcc, it should check the run-time version of ppl against the
version gcc was built with and if coherent pass that to cloog
which does the same and then checks for coherency against gcc's
ppl version.
   Jack

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc4x/cloog/ppl

[Jack Howarth]

On Fri, Aug 06, 2010 at 05:35:55PM +0200, Jean-François Mertens wrote:
>
> On 06 Aug 2010, at 17:32, Jean-François Mertens wrote:
>
>> As long a cloog's own install_name doesn't change, I see in principle 
>> no problem in
>> creating a new ppl pkg for the new version (since there the install  
>> name does change),
>> and to upgrade (independently, ie, whenever you want) cloog and one or 
>> more gccxy pkgs
>> to use the new ppl (and/or) the updated cloog.
>> I.e., cloog and gccxy using diferent ppl's should not be a problem per 
>> se
>> (as long as you can prevent cloog's flags for ppl to come before gcc's 
>> own flags in the
>> build of gcc; but that's at worst a flag-ordering problem).
>
> More explicity, for cloog it can be a plain version update, and things  
> that linked to
> the old version should continue linking well with the new, w/o  
> rebuilding.
>
> JF

JF,
   FYI, my interest from this comes from the following...

http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00159.html

With this merge -fgraphite-identity will be close to
a win (once the induct regression is fixed). It will be
interesting to see how much better those results are
against ppl-0.11 (compile time and run time) but I 
haven't puzzled out a clean way to upgrade my machine
without forcing a total rebuild of the gcc4x packages
against a new cloog built with ppl-0.11.
Jack

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc4x/cloog/ppl

[Jack Howarth]

On Fri, Aug 06, 2010 at 07:44:05PM +0200, Jean-François Mertens wrote:
>
>
> I can see no runtime problems, since thnigs are linked by install_name;
> even in the same binary, you could conceivably have 2 different symbols
> coming resp. from libfoo1.dylib and libfoo2.dylib.
> But here gcc would just link with cloog and the ppl it was built with,
> while cloog itself will link against whatever ppl it was built with.
> That is no problem.

JF,
   You're neglecting the fact that gcc loads the ppl headers via the
cloog headers. So even if gcc and cloog call their respective versions
of the ppl shared libraries, this won't account for possible differences in
the data structures in the two ppl releases. The cloog calls from gcc will
pass ppl data structures as defined by the ppl 0.10.x ABI while 
cloog will be assuming data structures as defined by the ppl 0.11
ABI. While you might get away with this, it certainly is playing
Russian roulette with the ABI.
 Jack
>
> JF

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] gcc 4.5.1 released

[Jack Howarth]

   Upstream has announced the official release of the
gcc 4.5.1 tarballs. If anyone is interested enough to
do the commits, the updated info and patch files have
been sitting on fink tracking for a week now...

http://sourceforge.net/tracker/?func=detail&aid=3037605&group_id=17203&atid=414256

This update provides functional link-time optimization
on x86_64-apple-darwin10 now. At -m64, LTO passes all of
its testsuite. The -m32 LTO since needs some work and
thus ins't enabled for the non-x86_64 variants. Note that
-fwhopr isn't really usable (for any target) on gcc 4.5.x
so stick with -flto (which can build the Polyhedron 2005
benchmarks).
Jack

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc 4.5.1 released

[Jack Howarth]

On Tue, Aug 10, 2010 at 09:18:39AM -0400, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 8/8/10 6:53 PM, Jack Howarth wrote:
> >Upstream has announced the official release of the
> > gcc 4.5.1 tarballs. If anyone is interested enough to
> > do the commits, the updated info and patch files have
> > been sitting on fink tracking for a week now...
> > 
> > http://sourceforge.net/tracker/?func=detail&aid=3037605&group_id=17203&atid=414256
> > 
> > This update provides functional link-time optimization
> > on x86_64-apple-darwin10 now. At -m64, LTO passes all of
> > its testsuite. The -m32 LTO since needs some work and
> > thus ins't enabled for the non-x86_64 variants. Note that
> > -fwhopr isn't really usable (for any target) on gcc 4.5.x
> > so stick with -flto (which can build the Polyhedron 2005
> > benchmarks).
> > Jack
> > 
> 
> We've got some test results.  Daniel J. did 10.6/i386 and 10.6/x86_64,
> and I believe there were no problems.  (Hopefully he'll report in to
> confirm this).
> 
> I did 10.5/i386, 10.5/PowerPC, and 10.4 PowerPC.  There were no problems
> on 10.5.  However, I did have an issue on 10.4--the end of the build
> gave the following messages:
> 
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Bootstrap comparison failure!
> gcc/cp/parser.o differs
> gcc/real.o differs
> gcc/tree-ssa-live.o differs
> gcc/tree-vectorizer.o differs
> 
> I posted the build log and build directory at
> 
> http://akhmac.blogdns.net/~hansen/finklogs/gcc-4.5.1-1000/

This machine appears to be inaccessible.

> 
> I don't have access to 10.4/i386, but Jack F. is currently trying that.
> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkxhUa4ACgkQB8UpO3rKjQ9pFACfdYltYGA5nzyIbrxpL9q8L/at
> sb4AoIi5EKhUz8mVcfqO1nG/+8KNvTcL
> =SlAl
> -END PGP SIGNATURE-

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc 4.5.1 released

[Jack Howarth]

On Tue, Aug 10, 2010 at 09:51:30AM -0400, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> > I posted the build log and build directory at
> > 
> > http://akhmac.blogdns.net/~hansen/finklogs/gcc-4.5.1-1000/
> > 
> >> This machine appears to be inaccessible.
> > 
> > 
> 
> Yeah, I rebooted it into 10.4 and I don't have the server mirrored.
> 
> It looks like my current gmp installation on 10.4 is from the Todai
> binary distribution and therefore built on a G5--I'd forgotten to check
> that before testing.  I'll rebuild gmp and then try gcc45 again.

Try adding --with-dwarf2 to configure in the gcc45-10.4.info script
for the darwin8 ppc builds. I am told this is required for 10.4
only.
   Jack

> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkxhWWIACgkQB8UpO3rKjQ/drQCfSuvpjdvKH4EcgBTGdZZ6eD3J
> trcAn3mkKrvfUS4cD4D8GKMFd6cc5iQq
> =zYgE
> -END PGP SIGNATURE-

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc 4.5.1 released

[Jack Howarth]

On Tue, Aug 10, 2010 at 07:42:05PM -0400, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 8/10/10 12:08 PM, Jack Howarth wrote:
> > On Tue, Aug 10, 2010 at 09:51:30AM -0400, Alexander Hansen wrote:
> > 
> >>>> I posted the build log and build directory at
> >>>>
> >>>> http://akhmac.blogdns.net/~hansen/finklogs/gcc-4.5.1-1000/
> >>>>
> >>>>> This machine appears to be inaccessible.
> >>>>
> >>>>
> > 
> > Yeah, I rebooted it into 10.4 and I don't have the server mirrored.
> > 
> > It looks like my current gmp installation on 10.4 is from the Todai
> > binary distribution and therefore built on a G5--I'd forgotten to check
> > that before testing.  I'll rebuild gmp and then try gcc45 again.
> > 
> >> Try adding --with-dwarf2 to configure in the gcc45-10.4.info script
> >> for the darwin8 ppc builds. I am told this is required for 10.4
> >> only.
> >>Jack
> > 
> That worked for me.  Jack F (cc'ed) reported that he wound up having
> this version of gcc45 not build on 10.4/Intel.  I don't know if he had
> the same build error as I did on PowerPC.  I've rebooted the machine so
> that the logs are accessible again.

Alexander,
   Try the attached gcc45-10.4.info and gcc45.patch which contains
an alternative fix of patching configure.ac to automatically invoke
--with-dwarf2 on darwin8.
Jack

> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkxh48wACgkQB8UpO3rKjQ93hgCfcHl4MSpVb6ti3cFzV31lDzXl
> U+0AoJskBfyttyx3eWU/RlQIVcRmKjHx
> =P8po
> -END PGP SIGNATURE-
Info2: <<
Package: gcc45
Version: 4.5.1
Revision: 1000
Source: ftp://gcc.gnu.org/pub/gcc/releases/gcc-%v/gcc-%v.tar.bz2
Source-MD5: 48231a8e33ed6e058a341c53b819de1a
Source2: ftp://sourceware.org/pub/java/ecj-latest.jar
Source2-MD5: fd299f26c02268878b5d6c0e86f57c43
PatchFile: %n.patch
PatchFile-MD5: dd05120ca330499c9d201ad1190a8cea
Distribution: 10.4
Type: -64bit -64bit
Architecture: powerpc, i386
NoSetCPPFLAGS: True
NoSetLDFLAGS: True
Conflicts: gcc42, gcc43, gcc44, gcc46
Replaces: gcc42, gcc43, gcc44, gcc46
Depends: %N-compiler (= %v-%r)
BuildDepends: gmp (>= 4.3.2-1), libmpfr1 (>= 2.4.2-2), libiconv-dev, 
gettext-tools, libgettext8-dev, libmpc2 (>= 0.8.1-1),  xcode (>= 2.5), fink (>= 
0.27.2)
ConfigureParams: <<
 --prefix=%p/lib/gcc4.5 --mandir=%p/share/man --infodir=%p/lib/gcc4.5/info  
--enable-languages=c,c++,fortran,objc,obj-c++,java \
 --with-gmp=%p --with-libiconv-prefix=%p --with-mpc=%p --with-system-zlib \
 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib 
--program-suffix=-fsf-4.5
<<
InfoTest: <<
   TestDepends: autogen, dejagnu
   TestScript: cd ../darwin_objdir; make -k check || :
<<
InfoDocs: cp-tools.info gcc.info gfortran.info cpp.info gccinstall.info 
libgomp.info cppinternals.info gccint.info gcj.info
CompileScript: <<
 #!/bin/bash -ev
 set +x
 if [ -e /usr/local/lib/libgmp.a ] || [ -e /usr/local/lib/libgmp.dylib ]; then
echo "-WARNING-WARNING-WARNING-"
echo "You seem to have GMP installed in /usr/local."
echo "This is known to cause %N to fail to build."
echo "Please move aside /usr/local and try again."
echo "-WARNING-WARNING-WARNING-"
exit 1
 fi
 set -x
 ulimit -s `ulimit -s`
 mv ../ecj-latest.jar ecj.jar
 mkdir ../darwin_objdir
 cd ../darwin_objdir
 ../gcc-%v/configure %c --disable-libjava-multilib
 num_cpu=$(echo `sysctl -n hw.ncpu`)
 make -j $num_cpu
 ##  make check requires autogen, dejagnu and expect, and should be run, in 
darwin_objdir, after install.
 ##  on 32-bit processors use
 # make -k check
 ##  on 64-bit processors use
 # make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
<<
InstallScript: <<
 #!/bin/sh -ev
 darwinvers=`uname -r`
 cd ../darwin_objdir
 make install DESTDIR=%d
 mkdir -p %i/bin

 # Add symlinks to recreate previous naming of executables in %p/bin
 # as well as %p/lib/gcc4.5/bin and new -fsf-4.5 naming in %p/bin.
 binfiles="gcc g++ c++ cpp gcov"
 for binfile in $binfiles ; do
   ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/lib/gcc4.5/bin/$binfile-4
   ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/bin/$binfile-4
   ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/bin/$binfile-fsf-4.5
 done
 binfiles="gfortran gcj gcj-dbtool gcjh gij gjnih grmiregistry grmic jcf-dump 
jv-convert jv-scan"
 for binfile in $binfiles ; do
   ln -s %p/lib/gcc4.5/bin/$binfile-fsf-4.5 %i/lib/gcc4.5/bin/$binfile
   ln -s %

Re: [Fink-devel] gcc 4.5.1 released

[Jack Howarth]

On Wed, Aug 11, 2010 at 07:48:45PM -0400, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 8/11/10 4:56 PM, Jack Fink wrote:
> > Salut Jack,
> > the problem on 10.4-i386 (with 2 dwarves) is that the build tries to build 
> > something as x86_64, which can't succeed with a 32bit libc.dylib.
> > Cheers (and thanks for putting that much brain/time/effort into gcc!)
> > 
> > -jack
> > 

Jack,
   Is this with Xcode 2.5? I'm surprised I didn't hear about this
problem before although I do see...

Historical Footnote: Compiling 64-Bit Command-Line Code for Mac OS X v10.4

Mac OS X v10.4 supports some 64-bit executables. However, Mac OS X v10.4 does 
not include a full 64-bit stack; Mac OS X v10.4 contains only libSystem and the 
Accelerate framework in 64-bit versions. In addition, Mac OS X 10.4 includes 
neither the Objective-C runtime nor a 64-bit Objective-C-capable version of 
dyld. Because of these differences, if you try to execute a 64-bit executable 
in 10.4 that depends on these 10.5-specific features, it would crash.

To prevent new 64-bit executables from running as 64-bit on version 10.4, Apple 
changed the CPU subtype for 64-bit executables that depend on high-level 
frameworks.

If you need to compile an executable as 64-bit for Mac OS X v10.4, you must 
select the 10.4 deployment target when building 64-bit executables and separate 
your code into a 32-bit front-end (GUI) portion and a 64-bit back-end 
(processing) portion.

at 
http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/64bitPorting/building/building.html.
Did the any of the previous gcc4x packages build the x86_64 multilib under 10.4?
 Jack

> 
> And you got an error with the prior iteration (no dwarf2) ?
> 
> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkxjNt0ACgkQB8UpO3rKjQ/fhwCffnfibclPfr7mwbYPFieaUT7N
> lnIAoKbESbsYKdrZxGFvpQlcFOSJvEGP
> =vXe6
> -END PGP SIGNATURE-

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc4x/cloog/ppl

[Jack Howarth]

   FYI, it is now clear what will happen upstream. The existing
cloog-ppl package will NOT be modified to build against the new
ppl-0.11 release. Instead it will be depreciated in favor of
the upcoming cloog.org release of cloog 0.15. The cloog.org
release of cloog can be built against a bundled isl library,
poly or ppl. There are no conflicts over soversions since
the cloog release creates libcloog-isl, libcloog-polylib and
libcloog-ppl shared libraries instead of just libcloog. At the
moment, it appears that only FSF gcc 4.6 and later will be
able to build against the newer cloog. The earlier gcc releases will
still have to be built against cloog-ppl and ppl-0.10.x.
   We will have to use a different package name (cloogorg.info?)
for the new cloog 0.15 release. At least we aren't in bad as 
shape as Debian. They got cute and renamed their shared lib
basenames from libcloog to libcloog-ppl and now have to lobby
upstream for a soversion bump to solve that conflict.
   Jack

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc 4.5.1 released

[Jack Howarth]

  Are we sure folks aren't having problems with the
existing gcc45-4.5.0-1000 release on 10.4? My undestanding
was that the same issue requiring --with-dwarf2 should
have existed there as well (since gcc 4.5 defaults to dwarf2
and gcc in the Xcode for 10.4 still defaults to stabs). 
 Jack


On Fri, Aug 13, 2010 at 02:08:09PM -0700, David R. Morrison wrote:
> Sounds good to me.  Maybe we should hear from the Jacks as well.
> 
>   -- Dave
> 
> 
> On Aug 13, 2010, at 1:57 PM, Alexander Hansen wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > How about if I implement the following then:
> > 
> > change the extant gcc45-10.4.info to look for gcc45-10.4.patch
> > copy the extant gcc45.patch to gcc45-10.4.patch
> > commit the 10.5 and 10.6-relevant files (gcc45.patch, gcc45.info,
> > gcc45-x86_64.info) from the tracker
> > 
> > ?
> > 
> > That way we will have the updated gcc45 in 10.5 and 10.6, with the
> > option to update it in 10.4.
> > 
> > On 8/11/10 9:19 PM, David R. Morrison wrote:
> >> If I could make a small suggestion on this thread.  Fink's support for 
> >> 10.4 will end fairly soon, so it would not be such a bad thing if gcc 
> >> 4.5.1 only runs on 10.5 and 10.6.
> >> 
> >>  -- Dave
> >> 
> >> 
> >> On Aug 11, 2010, at 5:36 PM, Jack Howarth wrote:
> >> 
> >>> On Wed, Aug 11, 2010 at 07:48:45PM -0400, Alexander Hansen wrote:
> >> On 8/11/10 4:56 PM, Jack Fink wrote:
> >>>>>> Salut Jack,
> >>>>>> the problem on 10.4-i386 (with 2 dwarves) is that the build tries to 
> >>>>>> build something as x86_64, which can't succeed with a 32bit libc.dylib.
> >>>>>> Cheers (and thanks for putting that much brain/time/effort into gcc!)
> >>>>>> 
> >>>>>> -jack
> >>>>>> 
> >>>> 
> >>>> Jack,
> >>>>  Is this with Xcode 2.5? I'm surprised I didn't hear about this
> >>>> problem before although I do see...
> >>>> 
> >>>> Historical Footnote: Compiling 64-Bit Command-Line Code for Mac OS X 
> >>>> v10.4
> >>>> 
> >>>> Mac OS X v10.4 supports some 64-bit executables. However, Mac OS X v10.4 
> >>>> does not include a full 64-bit stack; Mac OS X v10.4 contains only 
> >>>> libSystem and the Accelerate framework in 64-bit versions. In addition, 
> >>>> Mac OS X 10.4 includes neither the Objective-C runtime nor a 64-bit 
> >>>> Objective-C-capable version of dyld. Because of these differences, if 
> >>>> you try to execute a 64-bit executable in 10.4 that depends on these 
> >>>> 10.5-specific features, it would crash.
> >>>> 
> >>>> To prevent new 64-bit executables from running as 64-bit on version 
> >>>> 10.4, Apple changed the CPU subtype for 64-bit executables that depend 
> >>>> on high-level frameworks.
> >>>> 
> >>>> If you need to compile an executable as 64-bit for Mac OS X v10.4, you 
> >>>> must select the 10.4 deployment target when building 64-bit executables 
> >>>> and separate your code into a 32-bit front-end (GUI) portion and a 
> >>>> 64-bit back-end (processing) portion.
> >>>> 
> >>>> at 
> >>>> http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/64bitPorting/building/building.html.
> >>>> Did the any of the previous gcc4x packages build the x86_64 multilib 
> >>>> under 10.4?
> >>>>Jack
> >>>> 
> >> 
> >> And you got an error with the prior iteration (no dwarf2) ?
> >> 
> >>> 
> >>> --
> >>> This SF.net email is sponsored by 
> >>> 
> >>> Make an app they can't live without
> >>> Enter the BlackBerry Developer Challenge
> >>> http://p.sf.net/sfu/RIM-dev2dev 
> >>> ___
> >>> Fink-devel mailing list
> >>> Fink-devel@lists.sourceforge.net
> >>> http://news.gmane.org/gmane.os.apple.fink.devel
> >>> Subscription management:
> >>> https://lists.sourceforge.net/lists/listinfo/fink-devel
> > 
> > - -- 
> > Alexander Hansen
> > Fink User Liaison
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.10 (Darwin)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> > 
> > iEYEARECAAYFAkxlsb4ACgkQB8UpO3rKjQ9AJgCeOUNa981ur8/aA8geTh7q9sRy
> > a7MAnA054dX9k1lbtQA3YQQ3CwlNBl2K
> > =ZFu3
> > -END PGP SIGNATURE-

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] multiarch libraries in gcc44/45 on i386

[Jack Howarth]

Alexander,
Apple has always built libgcc in that manner. It is the one exception
in the multilib build where a separate subdirectory isn't used. The
new versioned libgcc_ext stubs (which provide all the additional symbols
from FSF libgcc which aren't in libgcc_s.10.4/10.5) is built the same way.
This is because libgcc_ext builds with the same infrastructure.
 Jack


On Wed, Aug 25, 2010 at 08:58:10PM -0400, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I'm not sure if this is intentional, but I get the following from
> gcc44-4.4.4-1000 (similarly for gcc45-4.5.0-1000) on 10.6/i386 and 10.5/i386
> 
> $ dpkg -L gcc44-shlibs | grep dylib | xargs file
> /sw32/lib/gcc4.4/lib/gcj-4.4.4-10/libjvm.dylib:Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libffi.4.dylib:   Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libgcc_s.1.dylib: Mach-O universal
> binary with 2 architectures
> /sw32/lib/gcc4.4/lib/libgcc_s.1.dylib (for architecture i386):Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libgcc_s.1.dylib (for architecture x86_64):  Mach-O
> 64-bit dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/libgcc_s.10.4.dylib:  Mach-O universal
> binary with 2 architectures
> /sw32/lib/gcc4.4/lib/libgcc_s.10.4.dylib (for architecture i386): Mach-O
> dynamically linked shared library stub i386
> /sw32/lib/gcc4.4/lib/libgcc_s.10.4.dylib (for architecture x86_64):
> Mach-O 64-bit dynamically linked shared library stub x86_64
> /sw32/lib/gcc4.4/lib/libgcc_s.10.5.dylib:  Mach-O universal
> binary with 2 architectures
> /sw32/lib/gcc4.4/lib/libgcc_s.10.5.dylib (for architecture i386): Mach-O
> dynamically linked shared library stub i386
> /sw32/lib/gcc4.4/lib/libgcc_s.10.5.dylib (for architecture x86_64):
> Mach-O 64-bit dynamically linked shared library stub x86_64
> /sw32/lib/gcc4.4/lib/libgcj-tools.10.dylib:Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libgcj.10.dylib:  Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libgfortran.3.dylib:  Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libgij.10.dylib:  Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libgomp.1.dylib:  Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libobjc-gnu.2.dylib:  Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libssp.0.dylib:   Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/libstdc++.6.dylib:Mach-O
> dynamically linked shared library i386
> /sw32/lib/gcc4.4/lib/x86_64/gcj-4.4.4-10/libjvm.dylib: Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libffi.4.dylib:Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libgcj-tools.10.dylib: Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libgcj.10.dylib:   Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libgfortran.3.dylib:   Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libgij.10.dylib:   Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libgomp.1.dylib:   Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libobjc-gnu.2.dylib:   Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libssp.0.dylib:Mach-O 64-bit
> dynamically linked shared library x86_64
> /sw32/lib/gcc4.4/lib/x86_64/libstdc++.6.dylib: Mach-O 64-bit
> dynamically linked shared library x86_64
> 
> The 64-bit libs aren't a problem, but the universal ones seem like
> they'd cause issues down the road.
> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEUEARECAAYFAkx1vCIACgkQB8UpO3rKjQ+b+gCghnGlt/Z4wpQb6qQ+Jtelr6gK
> FXUAkgP786OccF9aSGqKyHRZmfIQLAI=
> =PCSD
> -END PGP SIGNATURE-

--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourcefo

Re: [Fink-devel] llvm 10.4/ppc build fail

[Jack Howarth]

David,
   Did you try the packaging on fink tracking?

https://sourceforge.net/tracker/index.php?func=detail&aid=1859491&group_id=17203&atid=414256
https://sourceforge.net/tracker/index.php?func=detail&aid=2993939&group_id=17203&atid=414256
https://sourceforge.net/tracker/index.php?func=detail&aid=2982947&group_id=17203&atid=414256

I may revise the packaging soon for llvm-2.8, however I have found it is much 
more profitable
to spend my time getting patches into FSF gcc than hanging around here begging 
for commits.
  Jack
ps I just enabled LTO as default for darwin today in gcc trunk. I also just 
finished revising
how darwin handles the stack boundaries so we can have stack realignments...

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html

My hope is that the more generic we become in FSF gcc, the less of a regression 
magnet
we are.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc 4.5.1 released

[Jack Howarth]

On Fri, Sep 03, 2010 at 07:19:56PM -0400, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> OK.  I've been fighting with my own C++ code issues of late so I dropped
> out of the discussion.
> 
> Shall we go ahead and release this version into the wild?
> 
> On 8/14/10 6:46 PM, David Fang wrote:
> > Results on my slow-a** powerpc-apple-darwin8 are finally in!
> > http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01506.html
> > 
> > Latest packaging for 10.4(ppc) looks good to me.
> > 
> > I had one non-important suggestion for those of us who like to run the
> > testsuite: perhaps in TestScript, run the test_summary script and save
> > it to some file to be installed with docs/.  In the case when tests are
> > not run, perhaps touch an empty results file, so the .deb looks the same
> > whether or not the testsuite is run.
> > 
> > Fang
> > 
> 
> 

   I would go ahead and push them out. Ping me if there is any breakage but they
should be fine. My spare time has been soaked up with FSF gcc development. We
just eliminated all darwin-specific regressions in Link Time Optimization and
I enabled it as the default today. We also are looking at fixing the gcj 
failures under
darwin9 for gcc 4.6 as well as perhaps using the compact unwinder under
darwin10 instead of the older compatibility unwinder. We also have been
making changes so the the symlinks for libSystem are ignored during linkage
(such that a known order of linkage is always present...ie -lSystem last).
The rational for that change is to make sure that when the same symbol exists
in both libgcc_ext and libSystem (but is not marked as a magical symbol like
those in libgcc_s.10.4/10.5) the FSF gcc one is used. This came about from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 where the libSystem
___divdc3 call from http://compiler-rt.llvm.org/ is imprecise. Unfortunately
Apple deems this not interesting enough to fix. Before our rationalization
of the linkage, this bug would come or go depending if -lm was appended
(which promoted libSystem to the front of the linkage).
  Jack

> 
> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkyBgpwACgkQB8UpO3rKjQ/icACgoxpD8DUCb0+rQthakoHxQESl
> dDgAn2chuAW0UIwdf5rxL1jDDjT+xJ/H
> =vTA5
> -END PGP SIGNATURE-

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc 4.5.1 released

[Jack Howarth]

On Fri, Sep 03, 2010 at 07:19:56PM -0400, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> OK.  I've been fighting with my own C++ code issues of late so I dropped
> out of the discussion.
> 

Alexander,
   Actually, on reflection, let me backport one additional patch from
gcc-4_5-branch into that package. I discovered a memory corruption issue
in the compiler this week which could potentially randomize code generation
and it is fixed in both for both gcc trunk and 4.5.2...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484

   Jack

> 
> 
> 
> - -- 
> Alexander Hansen
> Fink User Liaison
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkyBgpwACgkQB8UpO3rKjQ/icACgoxpD8DUCb0+rQthakoHxQESl
> dDgAn2chuAW0UIwdf5rxL1jDDjT+xJ/H
> =vTA5
> -END PGP SIGNATURE-

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] ppl-0.11-1, cloog-ppl and gcc

[Jack Howarth]

Folks installing the new ppl 0.11.1 packaging should be aware that it
*could* cause breakage in pre-existing copies of gcc4x built against ppl 0.10.2.
The ppl 0.10.2 to 0.11.x transition represents an ABI change with soversion 
bump.
The potential problem stems from the fact that the graphite build of FSF gcc
uses the ppl headers so that one can end up with this situation...

1) Build gcc45 against ppl 0.10.2 and cloog built against ppl 0.10.2 as well.
2) Upgrade ppl to 0.11.x and then cloog built against the same.

Now you have a cloog-ppl built against one ppl ABI and a gcc45 graphite support
built against a older ppl ABI. While I can't prove this causes breakage but it
certainly is bad form.
The gcc 4.6.0 release will hopefully make this situation more robust. The
plans are to move from cloog-ppl to cloog.org's cloog release which will require
ppl 0.11.1 and then have gcc 4.6.0 itself require ppl 0.11.1 as well.

http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00849.html
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00853.html
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01033.html

Note that the second message is now untrue since cloog-ppl 0.15.10 should be
able to build against ppl 0.11.1 (and hence open the way for the mismatch).
  Jack

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] gcc45-4.5.2-1000

[Jack Howarth]

  I have placed updated gcc45-4.5.2-1000 packaging on fink tracking in case 
anyone
is interested in pushing it into fink unstable.

https://sourceforge.net/tracker/?func=detail&aid=3138732&group_id=17203&atid=414256

The packaging doesn't include a 10.4 variant due to the unresolved build issues
upstream for that target. This also was David Morrison's recommendation for the
previous uncommitted gcc45-4.5.1-1000 packaging.
   The new packaging requires an updated cloog package as well. This is present 
to
prepare for gcc46 which will use a cloog-org package instead (hence the addition
of a Conflicts/Replaces in cloog.info).
 Jack

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gcc45-4.5.2-1000

[Jack Howarth]

On Mon, Jan 17, 2011 at 09:38:23PM -0500, David Fang wrote:
> Jack,
>   Do you have a reference to what these 10.4 build issues are (thread or 
> bugzilla)?
>   Also, with your permission, can I enable cloog for 10.4?  The only  
> reason that I can see that it was restricted was because ppl didn't work  
> before, but I've since fixed it.  cloog validates for me cleanly on  
> powerpc-darwin8.  I'm hoping this would reduce the amount of work for  
> maintaining this family.
>   I can also validate cloog-org for you on 10.4 when it is ready.

Fang,
  This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248. Currently MacPorts
is taking the approach in their gcc45 package of building on darwin 8 with
--with-dwarf2 
(http://trac.macports.org/browser/trunk/dports/lang/gcc45/Portfile).
However Mike Stump rejected this change for upstream...

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00719.html

although Iain Sandoe was of a different opinion...

http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00723.html

Basically darwin8 is between a rock and a hard place. There are bootstrap issues
under stabs and the dwarf2 support in darwin8's Xcode is experimental. Also 
since 
there are no testers upstream for darwin8, the regression state of the resulting
compiler is questionable. Also if you read through the old thread in fink-devel
for gcc 4.5.1, Jack Fink claimed that dwarf2 was giving him problems on i386...

http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg20513.html

to which I replied...

http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg20515.html

Since David Morrison suggested we just nix further 10.4 packages...

http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg20516.html

I was leaning in that direction. Also since the security patch situation with
darwin8 is dicey, it seems unwise to encourage folks to keep running Tiger.
  Jack
>
> Fang
>
>>  I have placed updated gcc45-4.5.2-1000 packaging on fink tracking in  
>> case anyone is interested in pushing it into fink unstable.
>>
>> https://sourceforge.net/tracker/?func=detail&aid=3138732&group_id=17203&atid=414256
>>
>> The packaging doesn't include a 10.4 variant due to the unresolved build 
>> issues
>> upstream for that target. This also was David Morrison's recommendation for 
>> the
>> previous uncommitted gcc45-4.5.1-1000 packaging.
>>   The new packaging requires an updated cloog package as well. This is  
>> present to prepare for gcc46 which will use a cloog-org package instead 
>> (hence the addition of a Conflicts/Replaces in cloog.info).
>> Jack
>>
>> --
>> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
>> to consolidate database storage, standardize their database environment, and,
>> should the need arise, upgrade to a full multi-node Oracle RAC database
>> without downtime or disruption
>> http://p.sf.net/sfu/oracle-sfdevnl
>> ___
>> Fink-devel mailing list
>> Fink-devel@lists.sourceforge.net
>> http://news.gmane.org/gmane.os.apple.fink.devel
>> Subscription management:
>> https://lists.sourceforge.net/lists/listinfo/fink-devel
>>
>
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gmp5-64bit-5.0.1-5 build failure

[Jack Howarth]

Fang,
   You have to be extra careful with gmp because upstream doesn't
use the standard config.guess (which would make configuration much
more bullet proof).
Jack

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] ppl-0.10.2-4 fails tests on 10.5/i386

[Jack Howarth]

On Wed, Mar 23, 2011 at 10:28:04AM -0400, David Fang wrote:
>> It was originally thought that the failure was due to 10.5 using 
>> gcc-4.0, but the test still fails the same way with revision -4 which 
>> forces gcc-4.2.
>>
>> For the record, ppl9-0.11.2-1 does pass tests OK.  Would it make sense 
>> to update gcc-4(4/5) to use ppl9?
>
> Jack and I recently discussed a strategy for upgrading the  
> gmp/mpfr/mpc/ppl/cloog dependencies offline.  Jack, care to summarize?
>
> Fang

   Currently mpc and ppl9 are built against ppl9. The gcc44-4.4.5 package
however is incompatible with ppl9 and must be built against ppl for its graphite
support. The gcc45-4.5.3 (unreleased) package can be built against ppl9 but
requires the legacy cloog-ppl which is currently built against ppl. So we have
two options to complete the migration to gmp5/libmpfr4...

1) Patch ppl so it can be built against gmp5 and rebuild cloog against gmp5
as well as gcc44-4.4.5 and gcc45-4.5.3 against gmp5/libmpfr4.

2) Disable graphite in gcc44-4.4.5 using --without-ppl --without-cloog and
rebuild cloog against ppl9/gmp5 and gcc45-4.5.3 against 
ppl9/gmp5/libmpfr4/cloog.

I favor the second option myself since graphite is barely usable in gcc44. In
gcc45, graphite works reasonably well but it won't be until gcc46 that graphite
never misses vertorization opportunities.
  Jack

>
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] ppl-0.10.2-4 fails tests on 10.5/i386

[Jack Howarth]

On Wed, Mar 23, 2011 at 12:36:44PM -0400, David Fang wrote:
>> On Wed, Mar 23, 2011 at 10:28:04AM -0400, David Fang wrote:
 It was originally thought that the failure was due to 10.5 using
 gcc-4.0, but the test still fails the same way with revision -4 which
 forces gcc-4.2.

 For the record, ppl9-0.11.2-1 does pass tests OK.  Would it make sense
 to update gcc-4(4/5) to use ppl9?
>>>
>>> Jack and I recently discussed a strategy for upgrading the
>>> gmp/mpfr/mpc/ppl/cloog dependencies offline.  Jack, care to summarize?
>>>
>>> Fang
>>
>>   Currently mpc and ppl9 are built against ppl9. The gcc44-4.4.5 package
>> however is incompatible with ppl9 and must be built against ppl for its 
>> graphite
>> support. The gcc45-4.5.3 (unreleased) package can be built against ppl9 but
>> requires the legacy cloog-ppl which is currently built against ppl. So we 
>> have
>> two options to complete the migration to gmp5/libmpfr4...
>>
>> 1) Patch ppl so it can be built against gmp5 and rebuild cloog against gmp5
>> as well as gcc44-4.4.5 and gcc45-4.5.3 against gmp5/libmpfr4.
>
> So ppl in my experimental tree is built against gmp5 and exhibits the  
> exact same test failures that people are seeing.  [Need to report this  
> upstream to ppl-devel.] If you accept (?) that this new ppl-gmp5 is no  
> worse than ppl-gmp4, then 1) is feasible.

I'm agnostic on the issue really. Hopefully, once I have final patches in hand 
from
gcc-4_6-branch to fix lto against Xcode 3.2.6/4.0's assembler, we can get gcc46
in fink and push for a migration to it. The gcc46 package will have many 
advantages
including 1) usable lto, 2) usable objc/obj-c++ at -m64, 3) core2 tuning as 
default
and 4) excellent graphite performance (ie no vectorization loss).
 Jack
ps I posted this to the MacPorts list already. We had to disable lto in gcc 
4.6.0
on darwin10 due to an unfortunate change by Apple in their assembler for Xcode 
3.2.6
and 4.0 (which was self inflicted since it came from one of my radar reports). 
The
issue was that lto requires an unlimited number of sections in a mach-o file. 
The
mach-o spec is silent on that except for sections with relocations which are 
limited
to 255. We found that by placing the GNU LTO sections at the end of the mach-o 
file
we could avoid any issues with that limitation. However in Xcode 3.2.6/4.0, a 
hard
limit of 255 sections of any time was introduced in the assembler which makes 
lto
unusable for larger projects and fails parts of the lto testsuite. We have a 
work in
progress patch in hand but it will likely be several more weeks before it goes 
into
gcc trunk and gcc-4_6-branch. I plan on delaying the gcc46 package until I can 
back
port that and any other fixes for Xcode 4.0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108

>
>> 2) Disable graphite in gcc44-4.4.5 using --without-ppl --without-cloog  
>> and rebuild cloog against ppl9/gmp5 and gcc45-4.5.3 against  
>> ppl9/gmp5/libmpfr4/cloog.
>>
>> I favor the second option myself since graphite is barely usable in gcc44. In
>> gcc45, graphite works reasonably well but it won't be until gcc46 that 
>> graphite
>> never misses vertorization opportunities.
>>  Jack
>
>
>
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] ppl-0.10.2-4 fails tests on 10.5/i386

[Jack Howarth]

On Mon, Mar 28, 2011 at 09:03:10PM -0400, David Fang wrote:
>> On Wed, Mar 23, 2011 at 12:36:44PM -0400, David Fang wrote:
 On Wed, Mar 23, 2011 at 10:28:04AM -0400, David Fang wrote:
>> It was originally thought that the failure was due to 10.5 using
>> gcc-4.0, but the test still fails the same way with revision -4 which
>> forces gcc-4.2.
>>
>> For the record, ppl9-0.11.2-1 does pass tests OK.  Would it make sense
>> to update gcc-4(4/5) to use ppl9?
>
> Jack and I recently discussed a strategy for upgrading the
> gmp/mpfr/mpc/ppl/cloog dependencies offline.  Jack, care to summarize?
>
> Fang

   Currently mpc and ppl9 are built against ppl9. The gcc44-4.4.5 package
 however is incompatible with ppl9 and must be built against ppl for its 
 graphite
 support. The gcc45-4.5.3 (unreleased) package can be built against ppl9 but
 requires the legacy cloog-ppl which is currently built against ppl. So we 
 have
 two options to complete the migration to gmp5/libmpfr4...

 1) Patch ppl so it can be built against gmp5 and rebuild cloog against gmp5
 as well as gcc44-4.4.5 and gcc45-4.5.3 against gmp5/libmpfr4.
>>>
>>> So ppl in my experimental tree is built against gmp5 and exhibits the
>>> exact same test failures that people are seeing.  [Need to report this
>>> upstream to ppl-devel.] If you accept (?) that this new ppl-gmp5 is no
>>> worse than ppl-gmp4, then 1) is feasible.
>
> Following up on my end: I've reported the 0.10.2 test failure to  
> ppl-devel, also observing that gmp vs gmp5 makes no difference in the 
> test results.  Since ppl development seems focused on 0.11+, I kind of 
> doubt any fixes would come to 0.10.
>
> Jack, would it be acceptable for me to bump ppl to use gmp5 (as-is, in my 
> experimental tree)?  Along with it, older gcc4x's would need to inherit  
> ppl's updated dependencies for coherence.  AFAICS, gcc4x is the only  
> anti-dep of ppl.

  The gcc 4.4.x releases and earlier can't be built against ppl9. As I mentioned
before, the only sane approach is to update gcc44 to 4.4.5 and depreciate 
building
graphite in gcc44 at the same time with --without-ppl --without-cloog. This will
free us to update gcc45 and later to ppl9 and update legacy cloog to 0.15.10 
which
can be built against ppl9.
 Jack
ps I am holding off on gcc46 packages until Iain Sandoe finishes the gnu lto
containerization patch so that we can re-enable lto on darwin10. There are also
a few other minor testsuite failures introduced by Xcode 4.0 that might get 
fixed
as well.

>
> Fang
>
>> I'm agnostic on the issue really. Hopefully, once I have final patches  
>> in hand from gcc-4_6-branch to fix lto against Xcode 3.2.6/4.0's  
>> assembler, we can get gcc46 in fink and push for a migration to it. The 
>> gcc46 package will have many advantages including 1) usable lto, 2)  
>> usable objc/obj-c++ at -m64, 3) core2 tuning as default and 4) 
>> excellent graphite performance (ie no vectorization loss).
>> Jack ps I posted this to the MacPorts list already. We had  
>> to disable lto in gcc 4.6.0 on darwin10 due to an unfortunate change by 
>> Apple in their assembler for Xcode 3.2.6 and 4.0 (which was self  
>> inflicted since it came from one of my radar reports). The issue was  
>> that lto requires an unlimited number of sections in a mach-o file. The 
>> mach-o spec is silent on that except for sections with relocations 
>> which are limited to 255. We found that by placing the GNU LTO sections 
>> at the end of the mach-o file we could avoid any issues with that 
>> limitation. However in Xcode 3.2.6/4.0, a hard limit of 255 sections of 
>> any time was introduced in the assembler which makes lto unusable for 
>> larger projects and fails parts of the lto testsuite. We have a work in 
>> progress patch in hand but it will likely be several more weeks before 
>> it goes into gcc trunk and gcc-4_6-branch. I plan on delaying the gcc46 
>> package until I can back port that and any other fixes for Xcode 4.0.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48094
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48096
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108
>>
>>>
 2) Disable graphite in gcc44-4.4.5 using --without-ppl --without-cloog
 and rebuild cloog against ppl9/gmp5 and gcc45-4.5.3 against
 ppl9/gmp5/libmpfr4/cloog.

 I favor the second option myself since graphite is barely usable in gcc44. 
 In
 gcc45, graphite works reasonably well but it won't be until gcc46 that 
 graphite
 never misses vertorization opportunities.
  Jack
>>>
>>>
>>>
>>> David Fang
>>> http://www.csl.cornell.edu/~fang/
>>> http://www.achronix.com/
>>
>
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/

--
Enable yo

[Fink-devel] testing llvm-gcc

[Jack Howarth]

  It would be wise at this point to begin testing llvm-gcc on darwin10
as the replacement compiler for fink. I've already discovered that llvm-gcc
in Xcode 4.0.1 (and all llvm.org releases) miscompiles cc1 in recent FSF gcc...

http://llvm.org/bugs/show_bug.cgi?id=9571

The importance of testing this can be deduced from the most recent entry in...

http://www.nondot.org/sabre/Resume.html

Since Apple is unable to test any code which is now GPLv3, we should verify
all such packages in fink compile and pass their testsuite using llvm-gcc.
Unfortunately, llvm.org is depreciating llvm-gcc after the llvm 2.9 release
next week so motivating the linux llvm.org programmers (who are free to
touch GPLv3 code) to look at new llvm-gcc problems with GPLv3 code will be
increasingly problematic.
  Jack

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] testing llvm-gcc

[Jack Howarth]

  FYI, the code generation bug in llvm-gcc which breaks the FSF gcc has
been resolved...

http://llvm.org/bugs/show_bug.cgi?id=9571#c17

It is unclear if we can get this into llvm-gcc-4.2 2.9 (which is 
the last llvm.org release). I've also found a linker bug in
Xcode 4.0.1 when building gmp5 with clang (radar://9214380) and
a miscompilation of gmp/gmp5 with llvm-gcc (testsuite failures
and hangs)...

http://llvm.org/bugs/show_bug.cgi?id=9596

This last one seems to be specific to -mtune=core2 as I can't reproduce
the problem on x86_64 Fedora 14 with -mtune=k9.
Jack
ps We should identity as many of these issues with llvm-gcc/clang
as possible before Xcode 4.1 is released. Hopefully any fixes added to
Xcode 4.1 may be backported for one last Xcode 4.0.x release.

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] updated llvm-clang/llvm-gcc42 packaging and new dragonegg-gcc packaging

[Jack Howarth]

  I've uploaded a new llvm-clang package to replace the existing llvm
package and an updated llvm-gcc42 package. The llvm/llvm-gcc42 packages
haven't been updated before because of a leaky buildroot in llvm which
I fixed upstream in llvm 2.9...

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110228/117660.html

Prior to llvm 2.9, the previous llvm package had to be deinstalled to avoid
build issues when upgrading. This problem is eliminated in llvm 2.9.
  The dragonegg-gcc package builds against the plugin support in the 
gcc45-compiler
package. Currently dragonegg 2.9 only builds against gcc 4.5.x. The package is
installed as dragonegg-gcc45 and provides shell scripts with the de- prefix to
call the gcc45-compiler compilers with the dragonegg plugin. This version is
quite robust and passes the Polyhedron 2005 benchmarks. These packages are in
fink tracking at...

https://sourceforge.net/tracker/?func=detail&aid=3281454&group_id=17203&atid=414256

   Jack
ps Note that dragonegg isn't supporting powerpc. Also the large 
dragonegg-gcc.patch
is required to avoid a build failure on case-insensitive file systems.

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] updated llvm-clang/llvm-gcc42 packaging and new dragonegg-gcc packaging

[Jack Howarth]

On Sat, Apr 09, 2011 at 09:15:32AM -0400, Benjamin Reed wrote:
> On 4/8/11 9:51 PM, Jack Howarth wrote:
>>I've uploaded a new llvm-clang package to replace the existing llvm
>> package and an updated llvm-gcc42 package.
>
> I don't see how this could work; old llvm-gcc42 depends on "llvm" and  
> "llvm-shlibs" (with an = no less), so you can't have llvm-clang  
> Conflict/Replace llvm/llvm-shlibs without llvm-gcc42 holding it back.
>
> That's why newer llvms in fink are put off into %p/opt, because the  
> original llvm and llvm-gcc42 packages are un-upgradeable without manual  
> intervention.

Benjamin,
  Granted the original packaging was flawed but do we really want to keep
spinning off new llvm2x releases? The new packaging uses >= to it should
be upgradable from that point onwards. Once we hit llvm 3.0, llvm-gcc
disappears and dragonegg-gcc will Conflict/Replaces the old llvm-gcc42
package.
Jack

>
> -- 
> Benjamin Reed a.k.a. Ranger Rick a.k.a. Raccoon Fink
> Fink, KDE, and Mac OS X development
>
> Blog: http://www.raccoonfink.com/
> Music: http://music.raccoonfink.com/
>

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] using svn to pull source

[Jack Howarth]

  Do we have any approved examples of packages which pull their sources
dynamically from an svn repository? The newest dragonegg svn is quite
good against the release llvm 2.9 (building all of xplor-nih with
the three compilers, gcc, g++ and gfortran, all using the dragonegg plugin).
However the recent changes in the dragonegg svn makes the patch too large
to apply against dragonegg 2.9. It would be best to just have the
dragonegg-gcc package pull a specificed revision from the dragonegg trunk
svn and apply any patches needed to restore llvm 2.9 compatibility.
 Jack

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] using svn to pull source

[Jack Howarth]

Hanspeter,
   The dragonegg-gcc.info posted at 
http://sourceforge.net/tracker/?func=detail&aid=3281454&group_id=17203&atid=414256
works well enough so far. I used...

Source: none

with the svn download in the PatchScript...

PatchScript: <<
#!/bin/bash -ev
svn co -r129359 http://llvm.org/svn/llvm-project/dragonegg/trunk/ .
patch -p1 < %{PatchFile}
<<

For now I am setting...

Distribution: 10.5, 10.6

to avoid a dependency on the fink svn package. It would be nice if fink had a
virtual system-svn package that would resolve to the system svn on 10.5 and 
later
but resolve as the fink svn on 10.4. I hate to penalize the users of modern 
systems
by forcing them to needlessly build svn to build the package.
   Jack

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] using svn to pull source

[Jack Howarth]

On Wed, Apr 13, 2011 at 11:33:46AM -0700, David R. Morrison wrote:
> The problem with this approach is that it short-circuits one of Fink's 
> security features (the checking of MD5sum for source files) and it also 
> short-circuits Fink's storage of source files in its own archive to guard 
> against the day when the source file is no longer available from the original 
> distributor.
> 
>  -- Dave

Dave,
   Considering the lack of resources for fink, jumping through the hoops to get 
tarballs posted
is far more painful. MacPorts has supported this approach for quite some time 
now with their
svn.url/svn.revision fields. I used that approach in the MacPorts pymol package 
I maintain.
Jack
ps The posted packaging doesn't trigger any warnings with -m so I assumed it 
was acceptable to
code that way.

> 
> 
> On Apr 13, 2011, at 11:23 AM, Jack Howarth wrote:
> 
> > Hanspeter,
> >   The dragonegg-gcc.info posted at 
> > http://sourceforge.net/tracker/?func=detail&aid=3281454&group_id=17203&atid=414256
> > works well enough so far. I used...
> > 
> > Source: none
> > 
> > with the svn download in the PatchScript...
> > 
> > PatchScript: <<
> > #!/bin/bash -ev
> > svn co -r129359 http://llvm.org/svn/llvm-project/dragonegg/trunk/ .
> > patch -p1 < %{PatchFile}
> > <<
> > 
> > For now I am setting...
> > 
> > Distribution: 10.5, 10.6
> > 
> > to avoid a dependency on the fink svn package. It would be nice if fink had 
> > a
> > virtual system-svn package that would resolve to the system svn on 10.5 and 
> > later
> > but resolve as the fink svn on 10.4. I hate to penalize the users of modern 
> > systems
> > by forcing them to needlessly build svn to build the package.
> >   Jack
> > 
> > --
> > Forrester Wave Report - Recovery time is now measured in hours and minutes
> > not days. Key insights are discussed in the 2010 Forrester Wave Report as
> > part of an in-depth evaluation of disaster recovery service providers.
> > Forrester found the best-in-class provider in terms of services and vision.
> > Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> > ___
> > Fink-devel mailing list
> > Fink-devel@lists.sourceforge.net
> > List archive:
> > http://news.gmane.org/gmane.os.apple.fink.devel
> > Subscription management:
> > https://lists.sourceforge.net/lists/listinfo/fink-devel

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] using svn to pull source

[Jack Howarth]

On Wed, Apr 13, 2011 at 01:44:29PM -0500, Peter O'Gorman wrote:
> On 04/13/2011 01:23 PM, Jack Howarth wrote:
>> svn co -r129359http://llvm.org/svn/llvm-project/dragonegg/trunk/
>
> Jack,
>
> I have done:
>
> $ svn export -r129359 http://llvm.org/svn/llvm-project/dragonegg/trunk/  
> dragonegg-r129359
> $ tar cjf dragonegg-r129359.tar.bz2 dragonegg-r129359
>
> and put it at http://pogma.com/tmp/dragonegg-r129359.tar.bz2
>
> You can use that for your Source:, I will keep the file there as long as  
> needed. The advantage with this approach is that the source tarball will  
> get on the mirrors.
>
> Peter

Peter,
   Okay. I need to find out how long before FSF gcc 4.5.3 is released as
there is a useful fix from Duncan in gcc-4_5-branch...

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00682.html

Also, while dragonegg is rock solid in the default mode, I want to see how
many of the issues with -fplugin-arg-dragonegg-enable-gcc-optzns can be
fixed in the near term. This option causes all the gcc optimizations to be
executed before the LLVM IR is generated which can greatly enhance the
code optimization in dragonegg. Unfortunately, dragonegg doesn't understand
all of the nodes those optimizations generate in the GIMPLE (of which some of
may actually invalid GIMPLE).
   Jack

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] using svn to pull source

[Jack Howarth]

On Wed, Apr 13, 2011 at 01:44:29PM -0500, Peter O'Gorman wrote:
> On 04/13/2011 01:23 PM, Jack Howarth wrote:
>> svn co -r129359http://llvm.org/svn/llvm-project/dragonegg/trunk/
>
> Jack,
>
> I have done:
>
> $ svn export -r129359 http://llvm.org/svn/llvm-project/dragonegg/trunk/  
> dragonegg-r129359
> $ tar cjf dragonegg-r129359.tar.bz2 dragonegg-r129359
>
> and put it at http://pogma.com/tmp/dragonegg-r129359.tar.bz2
>
> You can use that for your Source:, I will keep the file there as long as  
> needed. The advantage with this approach is that the source tarball will  
> get on the mirrors.
>
> Peter

Peter,
   I'll revise the dragonegg-gcc packaging over the weekend to use your
tarball. We are making progress in dragonegg svn but Duncan rearranges
the source tree too much to maintain compatibility with llvm 2.9. The
stock usage of dragonegg is rock solid. The 
-fplugin-arg-dragonegg-enable-gcc-optzns
option (which significantly enhances the code generation) will be a highly
iterative process as it exposes layers of GIMPLE incompatibilities that
haven't been addressed yet in dragonegg (because the default code generation
is so generic).
Jack

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] glew needs update to 1.5.8

[Jack Howarth]

   The new OpenGL shader support I enabled in the current pymol-py packaging
doesn't work properly under the older glew package currently in unstable...

 There was an error intializing GLEW.  Basic graphics, including
 shaders and volumes may be unavailable.
 GLEW-Error: GLX 1.2 and up are not supported
 OpenGL graphics engine:
  GL_VENDOR: NVIDIA Corporation
  GL_RENDERER: NVIDIA GeForce GT 120 OpenGL Engine
  GL_VERSION: 2.1 NVIDIA-1.6.26
 Detected 16 CPU cores.  Enabled multithreaded rendering.
 OpenGL quad-buffer stereo 3D detected and enabled.

Updating glew to the current 1.5.8 release solves the runtime problems...

 Detected OpenGL version 2.0 or greater.  Shaders available.
 Detected GLSL version 1.20.
 OpenGL graphics engine:
  GL_VENDOR: NVIDIA Corporation
  GL_RENDERER: NVIDIA GeForce GT 120 OpenGL Engine
  GL_VERSION: 2.1 NVIDIA-1.6.26
 Detected 16 CPU cores.  Enabled multithreaded rendering.

Benjamin, can we get an update of glew to 1.5.8 in unstable?
   Jack

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] UseMaxBuildJobs

[Jack Howarth]

   I am open to switching the gcc4x packages to build using
UseMaxBuildJobs but I have one major complaint about how fink
currently handles this option. It is really unrealistic to expect
the users to create this entry in fink.conf on existing installations.
It would be nice if the next minor fink update could be changed to
automatically create UseMaxBuildJobs if it doesn't currently
exist in fink.conf. This would limit the annoyance of users as
packages are transitioned to UseMaxBuildJobs.
   Jack
ps Unless I missed it somehow, fink validate doesn't seem to demand
a particular fink version for this flag. Should this require a BuildDepends
on a particular fink release?

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] UseMaxBuildJobs

[Jack Howarth]

Daniel,
   It seems like a chicken and the egg problem here with UseMaxBuildJobs.
If the feature is considered entirely optional, it is difficult to rationalize
using it in larger packages that beg to be built with parallel make whenever
possible. Also, one can argue that there is inconsistent behavior currently
in fink. If one does a clean installation from fink cvs, the UseMaxBuildJobs
is automatically created in fink.conf for the user. I am only saying that
this behavior should be extended to existing installations of fink when
fink itself is upgraded as well. It is difficult to see how one can say
it is okay to silently create UseMaxBuildJobs for a fresh install of fink
without warning the user but that this is inappropriate for existing
installations of fink. They should be treated identically regarding the
autocreation of UseMaxBuildJobs in fink.conf.
Jack
ps Ny view is that if the user objects to UseMaxBuildJobs, they could set
it to 1 and, since UseMaxBuildJobs now exists, fink will never mess with
UseMaxBuildJobs in fink.conf again. I am only worried about the fact that
few if any users will expend the effort to discover this new option and
manually create it themselves.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] UseMaxBuildJobs

[Jack Howarth]

Hanspeter,
   I would definitely make the default to install the UseMaxBuildJobs entry
in fink.conf and make it an opt out. Currently it is an opt in for developers
to use this feature. However if we create an additional threshold which 
discourages
users from enabling features (because lots of them won't read the prompts but 
will
CR through them), it is difficult to encourage developers to switch their
packages to this feature for parallel makes.

Daniel,
With regard to disabling the feature, I don't see the problem with either
the non-default fink prompt to disable the feature adding a UseMaxBuildJobs=1
entry in fink.conf and then the mere existant of the UseMaxBuildJobs field
in fink.conf being sufficient for fink to never bother the user about it again.
I am mainly concerned that, if the creation of UseMaxBuildJobs is optional, lots
of users will inadvertently avoid creating it and thus hobble the builds of
large packages like gcc4x.
Jack

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] UseMaxBuildJobs

[Jack Howarth]

On Mon, May 02, 2011 at 11:43:08AM -0400, Benjamin Reed wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 5/2/11 10:09 AM, Jack Howarth wrote:
> > make it an opt out
> 
> The problem with making it an opt out is that there are plenty of
> packages that do not support parallel build, and the first rule is Don't
> Break Existing (Working) Stuff.
> 
> Enabling it by default that means that a bunch of maintainers who
> haven't heard anything about working packages for years will suddenly
> get reports of random failing.  Not really a good thing IMHO, especially
> since parallel-make issues are generally non-obvious and difficult to debug.

Benjamin,
I think you misunderstood my request. I am not asking that...

UseMaxBuildJobs: true

be default on. Rather I am asking that fink extends its current behavior
for new installations of defaulting to adding an entry for

UseMaxBuildJobs=N

in fink.conf when not present in existing installations. This in no way would
cause all packages to use UseMaxBuildJobs but rather only insure that those
that do currently use UseMaxBuildJobs are given access to the appropriate
number of jobs. Currently, the vast majority of users with existing 
installations
are unlikey to have UseMaxBuildJobs in fink.conf and we shouldn't make them
dive into the documentation for that feature to work on packages that currently
are coded to use it. 
 Jack
ps As I mentioned earlier, if a user doesn't want UseMaxBuildJobs to be used
in packages at all, they are free to set UseMaxBuildJob=1 in fink.conf and
fink should respect that and never attempt to change it.

> 
> - -- 
> Benjamin Reed a.k.a. Ranger Rick a.k.a. Raccoon Fink
> Fink, KDE, and Mac OS X development
> 
> Blog: http://www.raccoonfink.com/
> Music: http://music.raccoonfink.com/
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iD8DBQFNvtELUu+jZtP2Zf4RArwmAJ0elNvd6BpvhtIt1Uy4Yu3YFy2JjACePilO
> xAognpWjFubkEdYjlokKZRA=
> =bTjz
> -END PGP SIGNATURE-

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] readline packaging glitch

[Jack Howarth]

  While building fink packages with clang on SL, I noticed a glitch in the 
readline package.
It fails to link with clang 2.9svn as...

clang  -dynamiclib -arch_only `/usr/bin/arch` -install_name /sw/lib/`echo 
libreadline.4.3.dylib | sed "s:\(.*\.[0-9]\)\.[0-9]:\1:"` -current_version 4.3 
-compatibility_version 4.2.0 -v -o libreadline.4.3.dylib readline.so vi_mode.so 
funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so 
isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so 
callback.so terminal.so text.so nls.so misc.so xmalloc.so history.so 
histexpand.so histfile.so histsearch.so shell.so mbutil.so tilde.so compat.so 
-L/sw/lib -lncurses
Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn)
Target: x86_64-apple-darwin10
Thread model: posix
clang: error: no such file or directory: 'i386'

This appears to be due to the line in the readline.patch...

+   SHLIB_XLDFLAGS='-dynamiclib -arch_only `/usr/bin/arch` -install_name 
$(libdir)/`echo $@ | sed "s:\\(.*\\.[0-9]\\)\\.[0-9]:\\1:"` -current_version 
$(SHLIB_MAJOR)$(SHLIB_MINOR) -compatibility_version 4.2.0 -v'
 
which on x86_64 fink incorrectly reports i386 instead of x86_64 since 
/usr/bin/arch reports on the running
kernel and not the default binary execution type of Snow Leopard.
  Jack

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] llvm-gcc gmp fix

[Jack Howarth]

   Currently gmp 5.0.2 fails to pass its make check when built with llvm-gcc.
This is a permutation of the problem we previously saw with clang which resulted
in the change of the "checking how to switch to read-only data section..." test
from...

const int foo = 123;

to..

extern const int foo;   /* Suppresses C++'s suppression of foo */
const int foo = {1,2,3};

However this form of the test still results in the test incorrectly returning

.section__TEXT,__literal4,4byte_literals

using llvm-gcc and is the cause of the gmp testsuite failures. The fix
that has worked for me is to convert the test to...

static int foo = {1,2,3};

which works with both clang and llvm-gcc. I have attached a patch for this 
change
for inclusion in the gmp5-5.0.2 package.
Jack
--- gmp-5.0.2/configure.orig2011-05-16 17:59:59.0 -0400
+++ gmp-5.0.2/configure 2011-05-16 18:00:36.0 -0400
@@ -26446,8 +26446,8 @@
 esac
 
 cat >conftest.c <&5
 cat conftest.c >&5
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] default fink 10.7+ to x86_6only and clang

[Jack Howarth]

  Since it is unclear how many fink developers are testing Lion but
not subscribed to fink-seeding, I wanted to point out the proposed patch
at 
https://sourceforge.net/tracker/?func=detail&aid=3314492&group_id=17203&atid=317203.
This patch for fink cvs contains the following changes...

1) For 10.7 and later, only the x86_64 distibution is supported.
2) The bootstrap aborts in the absence of an installed Java SDK and
   ask the user to retry the bootstrap after installing it.
3) The path-prefix-clang symlink directory is created on 10.7 and
   later so that the cc/gcc compilers are symlinked to clang and c++/g++
   are symlinked to clang++ via a compiler wrapper.

Note that this patch requires the 2011 WWDC Xcode 4.1 release to avoid
http://llvm.org/bugs/show_bug.cgi?id=9862. Be aware that clang is more
strict on language compliance issues but these are easily fixed and often
immediately solved with a quick google search (eq main can't return an
unsigned int, etc).
 Jack
ps I originally had implemented a UseClang fink.conf parameter but the
consensus seems to be that fink should build in a uniform manner on all
10.7+ machines so the compiler is defaulted to clang instead.

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] clang now default in fink cvs for 10.7+

[Jack Howarth]

   To update the previous message on the proposed clang default compiler
support for Lion, this change is now checked into fink cvs. However the
portion checking for the Java SDK installation wasn't so be aware that
you will need to manually abort the bootstrap until that is installed.
The reason is that the libiconv package build triggers the Java SDK
installation while assuming it is present. This creates a race condition
in that build where the user must complete the Java SDK installation before
the libiconv build tries to use it. Hopefully this will be fixed shortly
with the commital of that section of my patch.

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] libidn broken on 10.5

[Jack Howarth]

Benjamin,
   Due to the fact that gcj is broken for java compilation (but not classes) on 
10.5,
the libidn package build fails if gcc45 is installed. Your packaging doesn't
appear to be trying use gcj but that gets tested against (which hangs) if
gcc45 is installed. Since that is now only a small symlink package, you can
fix this by just adding a BuildConflicts on gcc45. Note that packages really
shouldn't even be using the gcc4x packages in BuildDepends as they can now
use the non-conflicting gcc4x-compiler package and set FC=gfortran-fsf-4.x
etc.
Jack

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] 10.4-EOL and depreciating packages

[Jack Howarth]

  Can we leverage the new 10.4-EOL to help depreciate out some of the oldest
legacy packages in 10.4 (which is now 10.5 in all but name)? We have some
packages (like postgresql*) which many legacy versions. For those packages which
have no current packages depending on them and aren't supported with security
patches from upstream, it would be nice if we could depreciate them out of 10.4
and into 10.4-EOL. For example, llvm/llvm-gcc42 could be depreciated out in
favor of the new llvm29-style packages (which are more appropriate for the
dragonegg-gcc package which replaces llvm-gcc42).
  Jack

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] 10.7 status

[Jack Howarth]

   Do we actually plan on adding the packages into 10.7 in dribs and drabs?
In  pre-10.7 we had support for large builds like 'fink install gnuplot' and
'fink install pymol-py26' against clang. Attached is fink_packages.txt from...

dpkg --get-selections | cut -f1 > fink_packages.txt

on my 10.7 box from yesterday's 10.4 tree. It would make much more sense to
move the package files known to work over into 10.7 and clean them up in place.
We also should define best practices for the new 10.7. For instance, we don't
need Distribution or Architecture fields in the info files. Also, we could drop 
the
large revisions (eg -1000 becomes -1). It seems a bit late for major changes 
like
dropping -64bit as we have some much else on our plate with the transition to 
10.7
and clang. Also, while it might be nice to add a wrapper for cpp as 'clang -E',
this should only be done after we have stabilized 10.7 so that we can properly
guage how much breakage that introduces (since clang defaults to -std=c90).
  Jack

apbs
app-defaults
appleotffonts
applesystemfonts
apt
apt-dev
apt-shlibs
aquaterm
aquaterm-dev
aquaterm-shlibs
array-compare-pm5123
atk1
atk1-shlibs
autoconf2.6
automake1.11
avahi
base-files
bison
blt
blt-dev
blt-shlibs
bzip2
bzip2-dev
bzip2-shlibs
ca-bundle
cairo
cairo-shlibs
cloog-org
cloog-org-shlibs
cloog-shlibs
cmake
compress-raw-bzip2-pm5123
compress-raw-zlib-pm5123
cpan-meta-pm5123
cpan-meta-yaml-pm
cyrus-sasl2-dev
cyrus-sasl2-shlibs
daemonic
db43-ssl-shlibs
db48-aes-shlibs
db51-aes
db51-aes-shlibs
dbus
dbus-glib1.2-dev
dbus-glib1.2-shlibs
dbus1.3-dev
dbus1.3-shlibs
debianutils
default-icon-theme
devel-symdump-pm
docbook-dsssl-nwalsh
docbook-dtd
docbook-xsl
dos2unix
dpkg
dpkg-base-files
emacsen-common
encode-locale-pm5123
encode-pm5123
expat1
expat1-shlibs
exporter-pm
extutils-cbuilder-pm
extutils-command-pm
extutils-install-pm
extutils-makemaker-pm
extutils-makemaker-pm5123
extutils-manifest-pm
f2c
fftw3
fftw3-shlibs
file-copy-recursive-pm
file-listing-pm5123
file-temp-pm5123
fink
fink-mirrors
fink-obsolete-packages
fink-package-precedence
flag-sort
flex-devel
fondu
fontconfig-config
fontconfig2-dev
fontconfig2-shlibs
fort77
freeglut
freeglut-shlibs
freetype219
freetype219-shlibs
gawk
gcc44-compiler
gcc44-shlibs
gcc45-compiler
gcc45-shlibs
gcc46
gcc46-compiler
gcc46-shlibs
gcc47-compiler
gcc47-shlibs
gconf2
gconf2-dev
gconf2-shlibs
gd2
gd2-shlibs
gdbm3
gdbm3-shlibs
getoptbin
gettext-bin
gettext-tools
ghostscript
ghostscript-fonts
glew
glew-shlibs
glib2-dev
glib2-shlibs
glitz
glitz-shlibs
glpk-dev
glpk-shlibs
gmp5
gmp5-shlibs
gnome-base
gnome-common
gnome-doc-utils
gnome-icon-theme
gnome-mime-data
gnome-vfs2-unified-dev
gnome-vfs2-unified-shlibs
gnuplot
gst-plugins-base-0.10
gst-plugins-base-0.10-dev
gst-plugins-base-0.10-shlibs
gstreamer-0.10
gstreamer-0.10-dev
gstreamer-0.10-shlibs
gtk+2
gtk+2-dev
gtk+2-shlibs
gtk-doc
gzip
hdf5
hdf5-bin
hdf5-shlibs
help2man-perl5123
html-parser-pm5123
html-tagset-pm
http-cookies-pm5123
http-daemon-pm5123
http-date-pm5123
http-message-pm5123
http-negotiate-pm5123
icon-naming-utils
intltool40
io-compress-pm5123
io-socket-ssl-pm5123
json-pp-pm
libart2
libart2-shlibs
libavahi-client3-dev
libavahi-client3-shlibs
libavahi-common3-dev
libavahi-common3-shlibs
libavahi-core7-dev
libavahi-core7-shlibs
libavahi-glib1-dev
libavahi-glib1-shlibs
libcares2
libcares2-shlibs
libcdparanoia0-dev
libcdparanoia0-shlibs
libcurl4
libcurl4-shlibs
libdaemon
libdaemon-shlibs
libdatrie1
libdatrie1-shlibs
libgettext3-dev
libgettext3-shlibs
libgettext8-shlibs
libglade2
libglade2-shlibs
libgmpxx5-shlibs
libgnomecanvas2-dev
libgnomecanvas2-shlibs
libgnomecups-dev
libgnomecups-shlibs
libgnomeprint2.2-dev
libgnomeprint2.2-shlibs
libgnomeprintui2.2-dev
libgnomeprintui2.2-shlibs
libiconv
libiconv-bin
libiconv-dev
libidl2
libidl2-shlibs
libidn
libidn-shlibs
libjasper.1
libjasper.1-shlibs
libjpeg
libjpeg-bin
libjpeg-shlibs
libjpeg8-shlibs
libkpathsea6
libkpathsea6-shlibs
liblzma5-shlibs
libmpc2
libmpc2-shlibs
libmpfr4
libmpfr4-shlibs
libncurses5
libncurses5-shlibs
libncursesw5
libncursesw5-shlibs
libogg
libogg-shlibs
libopenjpeg
libopenjpeg-shlibs
libpaper1-dev
libpaper1-shlibs
libpng14-shlibs
libpng15-shlibs
libpng3
libpng3-shlibs
librarian.08-shlibs
librtmp
librtmp-shlibs
libsigsegv2
libsigsegv2-shlibs
libssh2.1
libssh2.1-shlibs
libthai
libthai-dev
libthai-shlibs
libtheora0
libtheora0-shlibs
libtheoradec1-shlibs
libtheoraenc1-shlibs
libtiff
libtiff-bin
libtiff-shlibs
libtool2
libtool2-shlibs
libvorbis0
libvorbis0-shlibs
libwww-pm5123
libxml2
libxml2-bin
libxml2-py26
libxml2-py27
libxml2-shlibs
libxslt
libxslt-bin
libxslt-shlibs
llvm30
locale-gettext-pm5123
lua51-dev
lua51-shlibs
lwp-mediatypes-pm5123
m4
meschach
meschach-shlibs
ncurses
net-http-pm5123
net-idn-encode-pm5123
net-idn-nameprep-pm5123
net-ssleay-pm5123
netpbm-bin
netpbm10
netpbm10-shlibs
nkf
numeric-py26
ocaml
octave
octave-shlibs
openjade
openldap24-dev
openldap24-shlibs
openmotif3
openmotif3-shlibs
opensp-bin
opensp5-dev
opensp5-shl

[Fink-devel] options for dropping Type: -64bit in 10.7

[Jack Howarth]

Dave,
Is it possible for us to drop "Type: -64bit" from 10.7, yet retain the
ability to properly package 32-bit shared libraries? Perhaps since we no longer
have to distinguish between a 32-bit package with 64-bit files and a 64-bit
package with 32-bit files, this issue is easier to solve in fink/dpkg. I would
like to retain the 32-bit compiler support in the gcc4x compiler packages but
without the need to use "Type: -64bit ." in order to package them. There are
a several reasons for this. The first is that --disable-multilib creates a
compiler that issues cryptic error messages about missing multilib files when
passed -m32 (which is suboptimal). The second is the absence of 32-bit support
in the compiler might encourage the installation of alternatively packaged
gcc compilers next to fink (which is bad). Lastly, I use the full multilib
packaging of gcc4x to routinely submit testsuite results upstream for gcc
trunk. Any ideas on how feasible it will be to solve this issue so -64bit
can be dropped but its core functionality retained?
 Jack

--
5 Ways to Improve & Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] 10.4-EOL, 10.5(aka 10.4), 10.7 and revision coherency

[Jack Howarth]

   Some consensus should be arrived at on how revisions should be set in the 
10.7
tree relative to 10.4-EOL/10.4(aka 10.5). For example, take the package foobar 
which
in 10.4 may have...

foobar.info with

Version: 1.0
Revision: 1000

foobar-x86_64.info with

Version: 1.0
Revision: 1001
Architecture: x86_64

so what should foobar in 10.7 be. I would argue for a full reset with...

foobar.info (no _x86_64 variant required)
Version: 1.0
Revision: 1

Otherwise, what is the correct answer?

foobar-1.0-1000
foobar-1.0-1001
foobar-1.0-1002

Unfortunately, I think extreme care will have to be taken when synchronizing the
trees since we will have lots of packages without x86_64 variants in 10.7 and
there is no longer a rationale for using the large revisions. It may even be 
true
that have a rupture between Revision numbering may help remind the maintainers
that foobar.info in 10.4 is radically different from foobar.info in 10.7.
 Jack

--
5 Ways to Improve & Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] 10.4-EOL, 10.5(aka 10.4), 10.7 and revision coherency

[Jack Howarth]

On Thu, Jul 21, 2011 at 09:45:05AM -0700, David R. Morrison wrote:
> Jack,
>
> Many of our package maintainers will now be faced with trying to  
> maintain a package across several distributions, and in cases where  
> there doesn't need to be a difference, the maintenance is easier if the 
> foo.info files are identical.
>

Dave,
   Okay, so we will retain the x86_64 variant naming even on 10.7. Some
thought will have to be given to packages like xmkmf.info which is 
currently patched to use llvm-gcc-4.2/llvm-cpp-4.2 at runtime. This is
more appropriate for Lion but if we intend to share that packaging
directly with the other trees the patch should be changed to use
gcc-4.2/cpp-4.2. However that will be a problem for 10.4_EOL.
Sharing the same files across three trees will be a challenge.
  Jack

> So generally, copying the same version, revision, architecture, and even 
> distribution information makes sense, since those things will enable the 
> same file to be used in three different places: (1) the 10.4-EOL tree for 
> the 10.4 distribution, (2) the 10.4 tree for the 10.5 and 10.6 
> distributions, and (3) the 10.7 tree for the 10.7 distribution.
>
>   -- Dave
>
> On Jul 21, 2011, at 9:11 AM, Jack Howarth wrote:
>
>>   Some consensus should be arrived at on how revisions should be set  
>> in the 10.7
>> tree relative to 10.4-EOL/10.4(aka 10.5). For example, take the  
>> package foobar which
>> in 10.4 may have...
>>
>> foobar.info with
>>
>> Version: 1.0
>> Revision: 1000
>>
>> foobar-x86_64.info with
>>
>> Version: 1.0
>> Revision: 1001
>> Architecture: x86_64
>>
>> so what should foobar in 10.7 be. I would argue for a full reset  
>> with...
>>
>> foobar.info (no _x86_64 variant required)
>> Version: 1.0
>> Revision: 1
>>
>> Otherwise, what is the correct answer?
>>
>> foobar-1.0-1000
>> foobar-1.0-1001
>> foobar-1.0-1002
>>
>> Unfortunately, I think extreme care will have to be taken when  
>> synchronizing the
>> trees since we will have lots of packages without x86_64 variants in  
>> 10.7 and
>> there is no longer a rationale for using the large revisions. It may  
>> even be true
>> that have a rupture between Revision numbering may help remind the  
>> maintainers
>> that foobar.info in 10.4 is radically different from foobar.info in  
>> 10.7.
>> Jack
>>
>> --
>> 5 Ways to Improve & Secure Unified Communications
>> Unified Communications promises greater efficiencies for business. UC 
>> can
>> improve internal communications as well as offer faster, more  
>> efficient ways
>> to interact with customers and streamline customer service. Learn  
>> more!
>> http://www.accelacomm.com/jaw/sfnl/114/51426253/
>> ___
>> Fink-devel mailing list
>> Fink-devel@lists.sourceforge.net
>> List archive:
>> http://news.gmane.org/gmane.os.apple.fink.devel
>> Subscription management:
>> https://lists.sourceforge.net/lists/listinfo/fink-devel

--
5 Ways to Improve & Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Problem resolving dependencies. Check for circular dependencies.

[Jack Howarth]

   As folks update their 10.7 trees today, we should attempt to debug the 
following
issue which also exists in 10.4 unstable. Last night I executed...

[MacPro:main/finkinfo/languages] howarth% fink -m install ghostscript
Scanning package description files..
Information about 811 packages read in 1 seconds.
Running in Maintainer Mode
Validating package file 
/sw/fink/dists/stable/main/finkinfo/text/ghostscript.info...
Package looks good!
The package 'ghostscript' will be built and installed.
Reading dependency for ghostscript-9.02-3...
Reading build dependency for ghostscript-9.02-3...
Reading build conflict for ghostscript-9.02-3...
WARNING: While resolving conflict "lcms" for package "ghostscript-9.02-3", 
package "lcms" was not found.
The package 'ghostscript-fonts' will be built and installed.
Reading dependency for ghostscript-fonts-8.11-3...
Reading build dependency for ghostscript-fonts-8.11-3...
Reading build conflict for ghostscript-fonts-8.11-3...
The package 'libtiff-shlibs' will be built and installed.
Reading dependency for libtiff-3.9.4-1...
Reading build dependency for libtiff-3.9.4-1...
Reading dependency for libtiff-shlibs-3.9.4-1...
Reading dependency for libtiff-bin-3.9.4-1...
Reading dependency for libtiff-shlibs-3.9.4-1...
Reading build dependency for libtiff-shlibs-3.9.4-1...
Reading build conflict for libtiff-3.9.4-1...
Reading build conflict for libtiff-shlibs-3.9.4-1...
The package 'libpaper1-shlibs' will be built and installed.
Reading dependency for libpaper1-1.1.24-1...
Reading build dependency for libpaper1-1.1.24-1...
Reading dependency for libpaper1-shlibs-1.1.24-1...
Reading dependency for libpaper1-dev-1.1.24-1...
Reading dependency for libpaper1-shlibs-1.1.24-1...
Reading build dependency for libpaper1-shlibs-1.1.24-1...
Reading build conflict for libpaper1-1.1.24-1...
Reading build conflict for libpaper1-shlibs-1.1.24-1...
The package 'libpng15-shlibs' will be built and installed.
Reading dependency for libpng15-1.5.2-1...
Reading build dependency for libpng15-1.5.2-1...
Reading dependency for libpng15-shlibs-1.5.2-1...
Reading dependency for libpng15-shlibs-1.5.2-1...
Reading build dependency for libpng15-shlibs-1.5.2-1...
Reading build conflict for libpng15-1.5.2-1...
Reading build conflict for libpng15-shlibs-1.5.2-1...
The package 'libjasper.1-shlibs' will be built and installed.
Reading dependency for libjasper.1-1.900.1-3...
Reading build dependency for libjasper.1-1.900.1-3...
Reading dependency for libjasper.1-shlibs-1.900.1-3...
Reading dependency for libjasper1-bin-1.900.1-3...
Reading dependency for jiv-1.900.1-3...
Reading dependency for libjasper.1-shlibs-1.900.1-3...
Reading build dependency for libjasper.1-shlibs-1.900.1-3...
Reading build conflict for libjasper.1-1.900.1-3...
Reading build conflict for libjasper.1-shlibs-1.900.1-3...
The package 'libidn-shlibs' will be built and installed.
Reading dependency for libidn-1.22-4...
Reading build dependency for libidn-1.22-4...
Reading dependency for libidn-shlibs-1.22-4...
Reading dependency for libidn-java-1.22-4...
Reading dependency for libidn-bin-1.22-4...
Reading dependency for libidn-shlibs-1.22-4...
Reading build dependency for libidn-shlibs-1.22-4...
Reading build conflict for libidn-1.22-4...
Reading build conflict for libidn-shlibs-1.22-4...
The package 'libtiff' will be built and installed.
Reading dependency for libtiff-3.9.4-1...
Reading build dependency for libtiff-3.9.4-1...
Reading dependency for libtiff-shlibs-3.9.4-1...
Reading dependency for libtiff-bin-3.9.4-1...
Reading build conflict for libtiff-3.9.4-1...
The package 'libpaper1-dev' will be built and installed.
Reading dependency for libpaper1-1.1.24-1...
Reading build dependency for libpaper1-1.1.24-1...
Reading dependency for libpaper1-shlibs-1.1.24-1...
Reading dependency for libpaper1-dev-1.1.24-1...
Reading dependency for libpaper1-dev-1.1.24-1...
Reading build dependency for libpaper1-dev-1.1.24-1...
Reading build conflict for libpaper1-1.1.24-1...
Reading build conflict for libpaper1-dev-1.1.24-1...
The package 'libpng15' will be built and installed.
Reading dependency for libpng15-1.5.2-1...
Reading build dependency for libpng15-1.5.2-1...
Reading dependency for libpng15-shlibs-1.5.2-1...
Reading build conflict for libpng15-1.5.2-1...
The package 'libjasper.1' will be built and installed.
Reading dependency for libjasper.1-1.900.1-3...
Reading build dependency for libjasper.1-1.900.1-3...
Reading dependency for libjasper.1-shlibs-1.900.1-3...
Reading dependency for libjasper1-bin-1.900.1-3...
Reading dependency for jiv-1.900.1-3...
Reading build conflict for libjasper.1-1.900.1-3...
The package 'libidn' will be built and installed.
Reading dependency for libidn-1.22-4...
Reading build dependency for libidn-1.22-4...
Reading dependency for libidn-shlibs-1.22-4...
Reading dependency for libidn-java-1.22-4...
Reading dependency for libidn-bin-1.22-4...
Reading build conflict for libidn-1.22-4...
The package 'libtool2' will

Re: [Fink-devel] Problem resolving dependencies. Check for circular dependencies.

[Jack Howarth]

On Fri, Jul 22, 2011 at 03:03:28PM +0200, Martin Costabel wrote:
> On 22/07/11 12:42, Jack Howarth wrote:
>> As folks update their 10.7 trees today, we should attempt to debug the 
>> following
>> issue which also exists in 10.4 unstable. Last night I executed...
>>
>> [MacPro:main/finkinfo/languages] howarth% fink -m install ghostscript
> []
>> The following 7 additional packages will be installed:
>>   desktop-file-utils glib2-dev glib2-shlibs gtk-doc libidn libidn-shlibs 
>> shared-mime-info
>> Do you want to continue? [Y/n]
>> Failed: Problem resolving dependencies. Check for circular dependencies.
>
> I think this is a known problem, has been on the lists a couple of  
> times: glib2-shlibs with -m does not work.

Martin,
   This was mentioned on IRC. We should make sure the effected info files have
a comment that -m causes a circular dependency for fresh bootstraps or such.
   Jack
>
> glib2-shlibs::TestInfo:TestDepends; shared-mime-info
> shared-mime-info::Depends: glib2-shlibs
>
> -- 
> Martin

--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] gc-7-1001 and Lion

[Jack Howarth]

Dave,
  FYI, David Fang asked me to test gc under Lion so that he can push guile20 
into 10.7.
I noticed you were missing an InfoTest and found when one was added to gc.info 
that the testsuite 
hung at...

Emulating dirty bits with mprotect/signals

This reminded that the same failures exist in the boehm-gc testsuite on FSF 
gcc...

http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01490.html

This is due to the gc code being incompatible with -pie. The solution is to pass
-Wl,-no_pie on the linker. The copy of gc.info placed in 10.7 will need the 
InfoTest
line...

InfoTest: TestScript: make -k check LDFLAGS="-Wl,-no_pie" || exit 2

It is unnecessary to use SetLDFLAGS:-Wl,-no_pie because the gc package doesn't 
contain
any executables. However you should put a comment in gc.info saying that any 
package
linking executables with the shared libs from the gc package should passs 
-no_pie
to the linker. FYI.
Jack

--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] gc-7-1001 and Lion

[Jack Howarth]

On Fri, Jul 22, 2011 at 05:45:42PM -0400, David Fang wrote:
> Also, I confirmed that InfoTest on powerpc-darwin8 passes its tests, but  
> with some (perhaps expected?) noise:
>
> http://paste.lisp.org/display/123443
>
> Ok for me to update gc in 10.4-EOL, with:
>
> InfoTest: TestScript: make -k check || exit 2

Only the linker in  Xcode 3.2.3 and later understands -no_pie.

> ?
>
> Fang
>
>> Dave,
>>  FYI, David Fang asked me to test gc under Lion so that he can push guile20 
>> into 10.7.
>> I noticed you were missing an InfoTest and found when one was added to 
>> gc.info that the testsuite
>> hung at...
>>
>> Emulating dirty bits with mprotect/signals
>>
>> This reminded that the same failures exist in the boehm-gc testsuite on FSF 
>> gcc...
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01490.html
>>
>> This is due to the gc code being incompatible with -pie. The solution is to 
>> pass
>> -Wl,-no_pie on the linker. The copy of gc.info placed in 10.7 will need the 
>> InfoTest
>> line...
>>
>> InfoTest: TestScript: make -k check LDFLAGS="-Wl,-no_pie" || exit 2
>>
>> It is unnecessary to use SetLDFLAGS:-Wl,-no_pie because the gc package 
>> doesn't contain
>> any executables. However you should put a comment in gc.info saying that any 
>> package
>> linking executables with the shared libs from the gc package should passs 
>> -no_pie
>> to the linker. FYI.
>>Jack
>>
>> --
>> 10 Tips for Better Web Security
>> Learn 10 ways to better secure your business today. Topics covered include:
>> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
>> security Microsoft Exchange, secure Instant Messaging, and much more.
>> http://www.accelacomm.com/jaw/sfnl/114/51426210/
>> ___
>> Fink-devel mailing list
>> Fink-devel@lists.sourceforge.net
>> List archive:
>> http://news.gmane.org/gmane.os.apple.fink.devel
>> Subscription management:
>> https://lists.sourceforge.net/lists/listinfo/fink-devel
>>
>
> -- 
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/

--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] depreciating numeric-py in 10.7

[Jack Howarth]

   Since we are attempting to modernize the fink 10.7 distribution by
eliminating older legacy packages like gcc44/gcc45 and python25, it
would be nice to extend this to numeric-py whose functionality exists
in numpy-py/scipy-py via the oldnumeric modules and friends. For example,
I have ported pymol-py to use numpy-py/scipy-py with the patch...

diff -uNr pymol-1.4/contrib/pyopengl/_glumodule.c 
pymol-1.4.scipy/contrib/pyopengl/_glumodule.c
--- pymol-1.4/contrib/pyopengl/_glumodule.c 2009-02-24 22:30:40.0 
-0500
+++ pymol-1.4.scipy/contrib/pyopengl/_glumodule.c   2011-07-22 
22:02:17.0 -0400
@@ -652,7 +652,7 @@
 #elif defined(HAVE_EXTENSIONS_ARRAYOBJECT_H)
 #include "Extensions/arrayobject.h"
 #elif defined(HAVE_NUMERIC_ARRAYOBJECT_H)
-#include "Numeric/arrayobject.h"
+#include "numpy/oldnumeric.h"
 #elif defined(HAVE_NUMERICAL_ARRAYOBJECT_H)
 #include "numerical/arrayobject.h"
 #else
diff -uNr pymol-1.4/contrib/pyopengl/_openglmodule.c 
pymol-1.4.scipy/contrib/pyopengl/_openglmodule.c
--- pymol-1.4/contrib/pyopengl/_openglmodule.c  2009-02-24 22:30:40.0 
-0500
+++ pymol-1.4.scipy/contrib/pyopengl/_openglmodule.c2011-07-22 
22:02:17.0 -0400
@@ -93,7 +93,7 @@
 #elif defined(HAVE_EXTENSIONS_ARRAYOBJECT_H)
 #include "Extensions/arrayobject.h"
 #elif defined(HAVE_NUMERIC_ARRAYOBJECT_H)
-#include "Numeric/arrayobject.h"
+#include "numpy/oldnumeric.h"
 #elif defined(HAVE_NUMERICAL_ARRAYOBJECT_H)
 #include "numerical/arrayobject.h"
 #else
diff -uNr pymol-1.4/contrib/pyopengl/openglutil.h 
pymol-1.4.scipy/contrib/pyopengl/openglutil.h
--- pymol-1.4/contrib/pyopengl/openglutil.h 2009-02-24 22:30:40.0 
-0500
+++ pymol-1.4.scipy/contrib/pyopengl/openglutil.h   2011-07-22 
22:02:17.0 -0400
@@ -14,7 +14,7 @@
 #elif defined(HAVE_EXTENSIONS_ARRAYOBJECT_H)
 #include "Extensions/arrayobject.h"
 #elif defined(HAVE_NUMERIC_ARRAYOBJECT_H)
-#include "Numeric/arrayobject.h"
+#include "numpy/oldnumeric.h"
 #elif defined(HAVE_NUMERICAL_ARRAYOBJECT_H)
 #include "numerical/arrayobject.h"
 #else
diff -uNr pymol-1.4/modules/pymol/opengl/__init__.py 
pymol-1.4.scipy/modules/pymol/opengl/__init__.py
--- pymol-1.4/modules/pymol/opengl/__init__.py  2009-02-24 22:29:21.0 
-0500
+++ pymol-1.4.scipy/modules/pymol/opengl/__init__.py2011-07-22 
22:02:17.0 -0400
@@ -1,7 +1,9 @@
+## Automatically adapted for numpy.oldnumeric Jul 09, 2010 by -c
+
 # PyOpenGL: modified for usage inside of PyMOL
 
 try:
-import multiarray
+import numpy.oldnumeric as multiarray
 _numeric = 1
 except ImportError:
 _numeric = 0
diff -uNr pymol-1.4/modules/pymol/opengl/gl/__init__.py 
pymol-1.4.scipy/modules/pymol/opengl/gl/__init__.py
--- pymol-1.4/modules/pymol/opengl/gl/__init__.py   2009-02-24 
22:29:21.0 -0500
+++ pymol-1.4.scipy/modules/pymol/opengl/gl/__init__.py 2011-07-22 
22:02:17.0 -0400
@@ -1,3 +1,5 @@
+## Automatically adapted for numpy.oldnumeric Jul 09, 2010 by -c
+
 import sys
 from pymol import opengl
 
@@ -13,7 +15,7 @@
 """
 
 if opengl._numeric:
-from Numeric import ArrayType
+from numpy.oldnumeric import ArrayType
 try:
 import _opengl_num
 _opengl = _opengl_num
diff -uNr pymol-1.4/modules/pymol/opengl/glu/__init__.py 
pymol-1.4.scipy/modules/pymol/opengl/glu/__init__.py
--- pymol-1.4/modules/pymol/opengl/glu/__init__.py  2009-02-24 
22:29:21.0 -0500
+++ pymol-1.4.scipy/modules/pymol/opengl/glu/__init__.py2011-07-22 
22:02:17.0 -0400
@@ -1,9 +1,11 @@
+## Automatically adapted for numpy.oldnumeric Jul 09, 2010 by -c
+
 # $Id: __init__.py 336 2001-02-24 12:11:45Z wdelano $
 import sys
 from pymol import opengl
 
 if opengl._numeric:
-from Numeric import ArrayType
+from numpy.oldnumeric import ArrayType
 try:
 import _glu_num
 _glu = _glu_num

and the manual edits on the bundled pynmr of...

perl -pi -e 's|Numeric import|numpy.oldnumeric import|g' *.py
perl -pi -e 's|LinearAlgebra import|numpy.oldnumeric.linear_algebra import|g' 
*.py

The same approach can be used for other packages which currently depend on 
numeric-py.
Alternatively some packages, like pdb2pqr 1.7, have already been enhanced to 
use either
numpy/scipy or Numeric if those can't be found.
Jack

--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] coreutils needs updated or regressed

[Jack Howarth]

   I appears from the announcements on the coreutils web site that the 8.10/8.11
releases may cause data loss.

http://savannah.gnu.org/forum/forum.php?forum_id=6785

* Noteworthy changes in release 8.11 (2011-04-13) [stable]
...
  cp -a --link would not create a hardlink to a symlink, instead
  copying the symlink and then not preserving its timestamp.
  [bug introduced in coreutils-8.0]

  cp now avoids FIEMAP issues with BTRFS before Linux 2.6.38,
  which could result in corrupt copies of sparse files.
  [bug introduced in coreutils-8.10]
...
** Changes in behavior

  cp now avoids syncing files when possible, when doing a FIEMAP copy.
  The sync is only needed on Linux kernels before 2.6.39.
  [The sync was introduced in coreutils-8.10]

  cp now copies empty extents efficiently, when doing a FIEMAP copy.
  It no longer reads the zero bytes from the input, and also can efficiently
  create a hole in the output file when --sparse=always is specified.

http://savannah.gnu.org/forum/forum.php?forum_id=6798

This is to announce coreutils-8.12, a stable release.

We released coreutils-8.11 less than two weeks ago.
Why a new release so soon?  Because under unusual conditions,
coreutils-8.11's copying code could cause trouble.  Data loss trouble.
The trouble could arise only when these conditions are all met:
  - when using linux-2.6.39-related kernels (including at least -rc3) and
  - using an xfs file system and
  - copying (via cp, install, mv) a file with a so-called "unwritten
  extent" shortly after it has been created, yet before some
  data in that unwritten extent has made it to disk.
  This would happen if you're using the "gold" linker, which
  preallocates using fallocate and then writes its output
  (the binaries) into those unwritten extents, and you then
  immediately copy those binaries into place via "make install".
Under those conditions, just building coreutils and running "make
install" quickly enough after compile and link would result in
installing files containing all 0 bytes.

So either we should regress to a version earlier than what we have
or hope that 8.12 really fixes all of the outstanding data loss
issues.
Jack

--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] tar-1.26-1

[Jack Howarth]

   I have been using the new tar-1.26-1 packaging that I placed on fink 
tracking...

http://sourceforge.net/tracker/?func=detail&aid=3373783&group_id=17203&atid=414256

for a week now and can happily report that, on x86_64 darwin11, it eliminates 
the
'file changed as we read it' warnings from fink/dpkg. There have been no 
instances
of corrupted debs after many builds of the gcc4x packages. This all isn't 
surprising
considering the changes in tar 1.26...

http://www.gnu.org/software/tar/

Work around POSIX incompatibilities on FreeBSD, NetBSD and Tru64.

as darwin is a BSD as well. Hopefully we can get this into 10.7 stable after a 
bit
of wider testing.
   Jack

--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] refactored openmpi packaging

[Jack Howarth]

   I've decided that the best approach for upgrading the openmpi package to the 
new 1.5.3 release
(which has an soversion bump) is to perform a clean break with the past 
lammpi/openmpi packaging
with 10.7. The original lammpi/openmpi packaging in 10.4 was modified to have 
co-existing main
packages as well as -shlibs but to have conflicting -dev packages (which also 
overlapped with
the system openmpi filenames). This work fairly well as it allowed both lammpi 
and openmpi to
be usable at the same time. It also had the benefit of exposing the system 
openmpi if the
-dev packages where deinstalled (in order to use that).
   Unfortunately the same approach isn't feasible with two openmpi major 
releases as they
share too many common filenames/directories that can't be easily renamed short 
of burying
them fully in /sw/opt/openmpi and /sw/opt/openmpi2 ala llvm29. However lammpi 
hasn't seen
a release since 2007 and should be considered fully depreciated in favor of 
openmpi (which
was the lammpi developer's intent). Also, since Lion no longer has a system 
openmpi, there
is no need or purpose for the -dev splitoff.
I made an attempt to create a refactored openmpi2 which had the just the 
main openmpi2
and openmpi2-shlibs splilt-off. However this approach impossible against the 
current openmpi
and lammpi packages. Since files in openmpi2 would now be common to both 
openmpi and the
openmpi-dev splitoff, both would have to Conflicts/Replaces on openmpi2. This 
is not
possible under fink. With all of this in mind, I have posted new packaging with 
the following
changes...

1) Both lammpi and openmpi are now set to Distribution: 10.4, 10.5, 10.6
2) An openmpi-10.7 variant is created for the new 1.5.3 release with 
Distribution: 10.7.
3) The openmpi-10.7 variant no longer buries itself with 
--libexecdir=%p/lib/%n. Also since
   we don't do binary distributions anymore I have removed the hacks for handle 
mpiCC, etc
   for now. If that proves to be a problem, I'll revisit it but the existing 
approach has
   misbehaved in the past with repeated install/remove/install cycles of the 
package.
4) I have left the shared libraries buried with --libdir=%p/lib/%n to avoid 
overlapping files
   with libotf.

Since we really only have few packages which use mpi (gromacs-mpi, fftw, 
paraview-mpi), the depreciation
of the lammpi package and refactoring of openmpi shouldn't be a huge deal. It 
will allow us
to have a much more sensible openmpi package going forward. The new packaging 
is in fink tracking
at...

http://sourceforge.net/tracker/index.php?func=detail&aid=3320182&group_id=17203&atid=414256

An update for gromacs/gromacs-mpi with a 10.7 variant of the later sans the 
openmpi variants
is available on fink tracking at...

http://sourceforge.net/tracker/?func=detail&aid=3379106&group_id=17203&atid=414256

Jack

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] hardened fink

[Jack Howarth]

  One issue that should be considered when deciding if fink 10.7 will support
some form of an upgrade installation option is the reduction in security from
that approach. By requiring a clean bootstrap of fink on Lion, we insure that
almost all packages are built with the default linker behavior of -pie. This
creation of position independent executables will provide fink users with
the added security of the full Address Space Layout Randomization in Lion.

http://en.wikipedia.org/wiki/Address_space_layout_randomization

The functionality of ASLR in Lion can be seen from the unique failure of
the gcc.dg/darwin-segaddr.c execution test in FSF gcc. That test case is
supposed to verify that a segment can be placed at the same address
each time. However if you add a printf to the testcase to output the
observed segaddr, you will find that when linked with the default -pie,
each execution of the resulting executable places the segment at a
different random address.
   The utility of such protection is on exhibit from Microsoft's recent
issues with rootkits that attack via the MBR...

http://www.f-secure.com/weblog/archives/1393.html

using a system call at a known location. The breakage occured when MS fixed
a 17 year old bug that moved the system call leveraged by the rootkit.
Had MS used full ASLR this attack would have never been possible in the
first place since the system call would have moved randomly in memory.
 Jack

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] hardened fink

[Jack Howarth]

On Wed, Jul 27, 2011 at 09:56:27PM -0400, Charles Lepple wrote:
> On Jul 27, 2011, at 2:03 PM, Jack Howarth wrote:
>
>> One issue that should be considered when deciding if fink 10.7 will  
>> support
>> some form of an upgrade installation option
>
> I haven't been following this too closely, but if there is a separate  
> 10.7 .info file tree, then I'm not sure a clean upgrade is possible  
> (especially considering what happens when a package hasn't been moved to 
> the 10.7 tree).

An unsupported trick exists to do an upgrade but as you mention below that
totally destroys the opportunity for major package cleanups. For example,
the is no clean way to refactor the existing openmpi into a much simplier 
form...

http://sourceforge.net/tracker/index.php?func=detail&aid=3320182&group_id=17203&atid=414256

with having a clean break at 10.7.
 Jack

>
> At the very least, it would be necessary to have some functionality to  
> clean up such orphaned packages, especially those related to older  
> versions of Perl and Python.

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] avoiding gcc-4.2

[Jack Howarth]

  I don't know if this is true, but someone on gmp-bugs claimed Xcode 4.2 will 
depreciate out
the Apple gcc-4.2 compiler. If this is true, we should attempt to favor 
llvm-gcc-4.2 on 10.7 fink
whenever clang is impossible to use for a package. Unless the problem is 
llvm-specific such
that llvm-gcc-4.2 won't work, we should avoid using SetCC/SetCXX and instead 
use...

if [[ $(sw_vers -productVersion | cut -d. -f1-2) > 10.6 ]]; then
  export CC=llvm-gcc-4.2
  export CXX=llvm-g++-4.2
fi

This should minimize the potential issues should Xcode 4.2 really ship without 
the legacy
Apple gcc-4.2 compilers.
  Jack

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] These packages work in 10.7, and I really need them ...

[Jack Howarth]

Hanspeter,
   The only gcc4x release in 10.7 stable will be gcc46 (or later). There should 
be no
issues updating fftw from gcc44 to gcc46. In any case, you should have an 
InfoTest
in fftw.info that will verify that the compiled code is passing its testsuite.
Every package in 10.7 stable should utilize an InfoTest if possible in order to
verify that the new default clang compilers produce no regressions and monitor 
this
in later Xcode releases.
Jack

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] unifying 10.4 stable/unstable

[Jack Howarth]

   Since 10.7 only has a stable tree, I think we should consider depreciating
the unstable tree in 10.4 as well. This would eliminate the confusion of pulling
the wrong info files over from 10.4 to 10.7 (from stable instead of unstable).
The sensible approach would appear to be copying all of 10.4 unstable into 10.4
stable and then depreciating 10.4 unstable into a symlink to 10.4 stable. Any
reason not to do this? Since we have no hope of obtaining the manpower to 
provide
binary releases, it is unclear why we are bothering with the pretence of a 10.4
stable tree.
 Jack

--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Move gcc46 to 10.5/stable branches ?

[Jack Howarth]

On Thu, Sep 15, 2011 at 02:32:52PM +0200, Sébastien Maret wrote:
> Hello,
> 
> Could gcc46 be moved to 10.5/stable and 10.6/stable ? One of my package 
> depends on that version of the compiler, so I can't move it to stable.
> 
> A more general question: now that we've only have a stable branch in 10.7, 
> wouldn't it make sense to drop the unstable branches in 10.5 and 10.6 (or 
> rather rename the unstable branches to stable) ? Maintaining stable and 
> unstable versions on 5 different OS/arch (10.7/x86_64, 10.6/x86_64, 10.5/i386 
> and 10.5/powerpc) is too much work for developers IMHO.

Sébastien,
   I suggested that we merge the current unstable 10.5/10.6 into stable 
10.5/10.6 a month
or so back. While there was general agreement that it made sense, nothing has 
been done yet.
It is pretty pointless for fink to maintaining the stable/unstable split with 
no prospects
of being able to do binary releases any time soon.
   Jack

> 
> Cheers,
> Sébastien
> 
> 
> , 

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] libmpfr4-shlibs : assertion failure on Fink install

[Jack Howarth]

On Mon, Oct 10, 2011 at 01:55:18PM -0400, David Fang wrote:
> I have another report that confirms breakage against Xcode-4.2 on 10.7.
>
> http://pastebin.com/s7u3R2Wh
>
> Unfortunately, I do not have this platform yet.  At this point, it might  
> be best to take this issue upstream.
>
> Fang

David,
   No idea as I don't have access to the pre-release Xcodes. Hopefully Xcode 4.2
will be released on Oct 12th and I can take a look at the issue. Since Xcode 4.2
is really iOS5 focused (and thus ARM-centric), I wouldn't be surprised something
doesn't pop up as a problem for intel-darwin. 
 Jack

>
>> Odd, I updated libmpfr4 after Jack Howarth (CCd) tested it for me.  
>> Jack, is anything visibly different between your configuration and 
>> theirs?
>>
>> Fang
>>
>>>  Hi
>>>
>>>  more data points: Xcode 4.2 on 10.6 and Xcode 4.1 on 10.7 was fine for me.
>>>
>>>  best
>>>  matthias
>>>
>>>  On 08.10.2011, at 20:27, David Palmer wrote:
>>>
>>> >  Using Xcode 4.2 under Lion 10.7.1 and a fresh install of fink, 
>>> when I >  try to do a source install of libmpfr4-shlibs, I get an 
>>> assertion >  failure
>>> > > >  ../../tests/tset_exp.c:44: MPFR assertion failed: ret == 0 &&  
>>> >  (__builtin_constant_p (2) && (mpfr_ulong) (2) == 0 ? (mpfr_sgn) 
>>> (x) : >  mpfr_cmp_ui_2exp ((x), (2), 0)) == 0
>>> > > >  Attached is the output file from
>>> >  % fink install libmpfr4-shlibs 2>&1 | tee /tmp/libmpfr4-shlibs.out
>>> >  
>>> > >  I have to ^C out of the build after the line
>>> >  /bin/sh: line 1: 22321 Segmentation fault: 11  MPFR_QUIET=1 ${dir}$tst
>>> >  FAIL: tabs
>>> > > >  More information:
>>> >  Package manager version: 0.31.2
>>> >  Distribution version: selfupdate-rsync Sat Oct  8 10:48:20 2011, 
>>> 10.7, >  x86_64
>>> >  Trees: local/main stable/main
>>> >  Xcode: 4.2
>>> > >  % gcc --version
>>> >  i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. 
>>> build >  5658) (LLVM build 2336.1.00)
>>> > > >  Based on
>>> >  
>>> > http://article.gmane.org/gmane.os.apple.fink.beginners/25590/match=libmpfr4
>>> >  I tried
>>> > %  fink update m4
>>> > %  fink self-update
>>> >  but that made no difference.
>>> > 
>>>
>>>
>>
>>
>
> -- 
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] libmpfr4-shlibs : assertion failure on Fink install

[Jack Howarth]

On Mon, Oct 10, 2011 at 01:55:18PM -0400, David Fang wrote:
> I have another report that confirms breakage against Xcode-4.2 on 10.7.
>
> http://pastebin.com/s7u3R2Wh
>
> Unfortunately, I do not have this platform yet.  At this point, it might  
> be best to take this issue upstream.
>
> Fang

David,
   One thing that the users with Xcode 4.2 might try is local builds with
SetCC=gcc-4.2/SetCXX=g++-4.2 as well as a build with 
SetCC=llvm-gcc/SetCXX=llvm-g++.
The results of those two builds would give us some idea if the problem is 
clang-specific,
llvm-specific or a linker issue.
 Hacj

>
>> Odd, I updated libmpfr4 after Jack Howarth (CCd) tested it for me.  
>> Jack, is anything visibly different between your configuration and 
>> theirs?
>>
>> Fang
>>
>>>  Hi
>>>
>>>  more data points: Xcode 4.2 on 10.6 and Xcode 4.1 on 10.7 was fine for me.
>>>
>>>  best
>>>  matthias
>>>
>>>  On 08.10.2011, at 20:27, David Palmer wrote:
>>>
>>> >  Using Xcode 4.2 under Lion 10.7.1 and a fresh install of fink, 
>>> when I >  try to do a source install of libmpfr4-shlibs, I get an 
>>> assertion >  failure
>>> > > >  ../../tests/tset_exp.c:44: MPFR assertion failed: ret == 0 &&  
>>> >  (__builtin_constant_p (2) && (mpfr_ulong) (2) == 0 ? (mpfr_sgn) 
>>> (x) : >  mpfr_cmp_ui_2exp ((x), (2), 0)) == 0
>>> > > >  Attached is the output file from
>>> >  % fink install libmpfr4-shlibs 2>&1 | tee /tmp/libmpfr4-shlibs.out
>>> >  
>>> > >  I have to ^C out of the build after the line
>>> >  /bin/sh: line 1: 22321 Segmentation fault: 11  MPFR_QUIET=1 ${dir}$tst
>>> >  FAIL: tabs
>>> > > >  More information:
>>> >  Package manager version: 0.31.2
>>> >  Distribution version: selfupdate-rsync Sat Oct  8 10:48:20 2011, 
>>> 10.7, >  x86_64
>>> >  Trees: local/main stable/main
>>> >  Xcode: 4.2
>>> > >  % gcc --version
>>> >  i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. 
>>> build >  5658) (LLVM build 2336.1.00)
>>> > > >  Based on
>>> >  
>>> > http://article.gmane.org/gmane.os.apple.fink.beginners/25590/match=libmpfr4
>>> >  I tried
>>> > %  fink update m4
>>> > %  fink self-update
>>> >  but that made no difference.
>>> > 
>>>
>>>
>>
>>
>
> -- 
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] libmpfr4-shlibs : assertion failure on Fink install

[Jack Howarth]

On Mon, Oct 10, 2011 at 11:17:27PM -0600, David Palmer wrote:
> I did  a survey of compilers to see what works and what doesn't.
> 
> In the .info file, I changed the ../configure line to 
> ../configure %c "CC=llvm-gcc -m64" "CXX=llvm-g++ -m64" 
> --libdir='${prefix}/%lib'
> etc.
> 
> llvm-gcc  PASSED
> llvm-gcc-4.2  PASSED
> clang   FAILED on the same assert as the original
> gcc-4.2   PASSED
> gcc-fsf-4.6  PASSED
> (I used fink to install gcc4.6 for the last one).
> 
> 
> Only clang seems to fail when the compiler is given explicitly in the 
> ../configure line
> 
> I am not really understanding this.  The unmodified version claims to be 
> compiling with 'gcc', and 
> % which gcc
> /usr/bin/gcc
> % ls -ls /usr/bin/gcc
> 8 lrwxr-xr-x  1 root  wheel  12 Oct  7 00:36 /usr/bin/gcc -> llvm-gcc-4.2
> 
> so there should be no difference between the original run (which doesn't 
> work) and the llbm-gcc-4.2 (which works).

David,
   Under fink 10.7, the clang compilers are used by default via prefix-clang 
symlinks (in the same manner
as symlinks are used to force -m64 for x86_64 fink). Your results suggest that 
we have run across a
clang regression introduced in Xcode 4.2 and that we will need to file a radar 
report on it. This isn't
surprising considering that the focus of Xcode 4.2 was iOS5 and thus ARM rather 
than intel. Also Apple
can't compile any GPLv3 sources so code like current mpfr goes untested. I'll 
try a fresh bootstrap of fink 10.7
once Xcode 4.2 is released to see how much damage Apple has done to clang in 
that release.
Jack
ps It is still unclear to me if Apple intends to automatically push out Xcode 
4.2 or if it will be
an opt-in only installation intended focused on iOS5 developers.

> 
> 
> 
> 
> 
> In the CompileScript secant, just before the ../configure line, there is 
> 
>   if [ "%type_raw[-64bit]" == "-64bit" ]; then
> export CC="gcc -m64"
>   fi
> 
> But changing those lines don't seem to have any effect on the compiler.  (I 
> don't know enough about .info files to know if that is the expected result)

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] libmpfr4-shlibs : assertion failure on Fink install

[Jack Howarth]

On Mon, Oct 10, 2011 at 11:17:27PM -0600, David Palmer wrote:
> I did  a survey of compilers to see what works and what doesn't.
> 
> In the .info file, I changed the ../configure line to 
> ../configure %c "CC=llvm-gcc -m64" "CXX=llvm-g++ -m64" 
> --libdir='${prefix}/%lib'
> etc.
> 
> llvm-gcc  PASSED
> llvm-gcc-4.2  PASSED
> clang   FAILED on the same assert as the original
> gcc-4.2   PASSED
> gcc-fsf-4.6  PASSED
> (I used fink to install gcc4.6 for the last one).
> 
> 
> Only clang seems to fail when the compiler is given explicitly in the 
> ../configure line
> 
> I am not really understanding this.  The unmodified version claims to be 
> compiling with 'gcc', and 
> % which gcc
> /usr/bin/gcc
> % ls -ls /usr/bin/gcc
> 8 lrwxr-xr-x  1 root  wheel  12 Oct  7 00:36 /usr/bin/gcc -> llvm-gcc-4.2
> 
> so there should be no difference between the original run (which doesn't 
> work) and the llbm-gcc-4.2 (which works).

David,
  Actually, I just tested upstream llvm/clang 3.0svn from llvm.org and am 
seeing failures there
as well..

[tversion] GMP: header 5.0.2, library 5.0.2
[tversion] MPFR tuning parameters from src/x86_64/core2/mparam.h
PASS: tversion
PASS: tinternals
PASS: tinits
PASS: tisqrt
PASS: tsgn
PASS: tcheck
PASS: tisnan
Error: emin >= emax
FAIL: texceptions
../../tests/tset_exp.c:44: MPFR assertion failed: ret == 0 && 
(__builtin_constant_p (2) && (mpfr_ulong) (2) == 0 ? (mpfr_sgn) (x) : 
mpfr_cmp_ui_2exp ((x), (2), 0)) == 0
/bin/sh: line 1: 91034 Abort trap: 6   MPFR_QUIET=1 ${dir}$tst
FAIL: tset_exp
/bin/sh: line 1: 91053 Segmentation fault: 11  MPFR_QUIET=1 ${dir}$tst
FAIL: tset
PASS: mpf_compat
Error in conversion to/from mpz
expected 17, got 0.e+00
FAIL: mpfr_compat
../../src/set_str_raw.c:54: MPFR assertion failed: res == 0
/bin/sh: line 1: 91105 Abort trap: 6   MPFR_QUIET=1 ${dir}$tst
FAIL: reuse
/bin/sh: line 1: 91123 Segmentation fault: 11  MPFR_QUIET=1 ${dir}$tst
FAIL: tabs

etc. So it looks like either a mpfr bug being tickled or a new flaw introduced
upstream in clang 3.0svn.
 Jack
> 
> 
> 
> 
> 
> In the CompileScript secant, just before the ../configure line, there is 
> 
>   if [ "%type_raw[-64bit]" == "-64bit" ]; then
> export CC="gcc -m64"
>   fi
> 
> But changing those lines don't seem to have any effect on the compiler.  (I 
> don't know enough about .info files to know if that is the expected result)

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] libmpfr4-shlibs : assertion failure on Fink install

[Jack Howarth]

David,
   I have puzzled this one out. Comparing the config.log's generated by Xcode 
4.1's clang and
the fink llvm29 package's clang, I see...

-checking for TLS support... no
+checking for TLS support... yes

If I simply append --disable-thread-safe to ConfigureParams in libmpfr4.info, I 
am able to build
the package against clang from either llvm29 or llvm30 without regressions. I 
strongly suspect this will
also fix the issues you are seeing with clang from Xcode 4.2.
Jack
ps I have opened up http://llvm.org/bugs/show_bug.cgi?id=1 to alert the 
clang developers of
this problem.

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] potential Xcode 4.2 problems

[Jack Howarth]

  When Xcode 4.2 is released, we will need to be alert for new build problems
on 10.7 stable. The Xcode 4.2's clang compilers now use the new TLS support
in the darwin11 SDK (which wasn't the case for Xcode 4.1). This has already
been discovered to break libmpfr4. If your package fails to pass it's testsuite
under Xcode 4.2 due to the TLS support malfunctioning, this can be avoided 
by either passing --disable-thread-safe to configure or if that isn't available
using -mmacosx-version-min=10.6 on the compile flags. FYI.
   Jack
ps Currently under Xcode 4.1, clang never provides TLS support (whereas llvm29
does and can be used to reproduce the problem under Lion).

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Potential Xcode 4.2 problems

[Jack Howarth]

 Sorry for the duplicate posting but the last seemed to go out empty.

 With the release of Xcode 4.2, we will have to be alert to package breakage
due to the newly enabled TLS support in clang under darwin11. This issue only
occurs on the darwin11 SDK using llvm.org's clang 2.9 or svn under Xcode 4.1/4.2
or with the clang3.0svn from Xcode 4.2. If you find out that your package now
fails its testsuite when built under Xcode 4.2, first try passing the configure
option, --disable-thread-safe, if available or -mmacosx-version-min=10.6 on the
compile flags if not. We have already found this problem exists in MPFR 3.1.0
under fink 10.7. Unfortunately this code is GPLv3 so Apple can't look at it
directly. Thus it would be very helpful if we can identfy another fink package
which isn't GPLv3 that exhibits the same problem to give Apple's developers
something they can work with directly. FYI, this issue exists upstream now as...
http://llvm.org/bugs/show_bug.cgi?id=1.
   Jack

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] smake build fixed with Xcode 4.2

[Jack Howarth]

  FYI, the problems with cdrtools building under Lion should be resolved with 
Xcode 4.2.
While I haven't tested that package yet, the underlying build issue with smake 
contained
in cdrtools is now fixed. The attached packaging builds smake without failures 
under
Xcode 4.2 (whereas Xcode 4.1 will hang the test avoffset). Nice.
  Jack
ps Of course the cdrtools package in 10.7 stable will need a BuildDepends of 
xcode (>= 4.2).
Package: smake
Version: 1.2.1
Revision: 1
Maintainer: Jack Howarth 
Source: ftp://ftp.berlios.de/pub/smake/%n-%v.tar.bz2
Source-MD5: 2fd7bd44b22da1640aaa6fbd31c727e4
PatchFile: %n.patch
PatchFile-MD5: 6c035ad2dc50bfd6b4249ec275a8f8f4
BuildDepends: fink (>= 0.24.12)
UseMaxBuildJobs: False
CompileScript: <<
gnumake
<<
InstallScript: <<
gnumake DESTDIR=%d install
<<
License: GPL
DocFiles: COPYING
Description: Portable make program with automake features
Homepage: http://cdrecord.berlios.de/old/private/smake.html
--- smake-1.2.1/autoconf/config.guess.orig  2011-07-24 11:54:30.0 
-0400
+++ smake-1.2.1/autoconf/config.guess   2011-07-24 11:54:10.0 -0400
@@ -858,6 +858,9 @@
 "x86":"Darwin":*)
echo i386-apple-macosx${UNAME_RELEASE}
exit 0 ;;
+"x86_64":"Darwin":*)
+echo i386-apple-macosx${UNAME_RELEASE}
+exit 0 ;;
 *:OS/2:*:*)
 echo "i386-pc-os2_emx"
exit 0;;
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] more Xcode 4.2 fixes

[Jack Howarth]

FYI, Apple has fixed a couple bugs we discovered in Xcode 4.0 and 4.1 with 
the new Xcode 4.2
release. The issue with gettext-tools' xgettext.c being miscompiled at -O2 
(which we worked around
with -O4) using clang from Xcode 4.1 has been fixed with a backport from 
llvm.org's svn.

http://llvm.org/bugs/show_bug.cgi?id=9892

I was also told, but haven't verified yet, that the i386 ocaml build issues are 
fixed in Xcode 4.2.
This isn't of much use for Lion and the access of Xcode 4.2 on SL will be quite 
limited as you have
to either have purchased Xcode 4.0 for SL when it was still available or have a 
paid ADC account.
   Jack

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

   The release of Xcode 4.2 for Snow Leopard presents fink with both a problem
and an opportunity. The Xcode 4.2 SL release defaults /usr/bin/gcc and 
/usr/bin/g++
to the llvm-gcc-4.2 and llvm-g++-4.2 compilers respectively. This exposes fink 
10.6
to a slew of llvm-gcc bugs (many yet unknown). Fortunately, the clang3.0svn in
Xcode 4.2 on SL appears to be quite good and allows us to leverage the current
path-prefix-clang support in fink. The attached patch does this whenever a 
symlink
for llvm-gcc-4.2 is found for /usr/bin/gcc on 10.6. This patch allows fink
0.31.3 to cleanly bootstrap using clang/clang++ on 10.6 with Xcode 4.2 
installed.
   I will admit that the Xcode 4.2 release on SL is problematic because new 
copies
are no longer sold from the App Store. On the otherhand, it is freely available
from the App Store for users who previously purchased Xcode 4.0. With this in 
mind,
I would suggest we assume all users with Xcode 4.0 have access to 4.2 and that 
they
should upgrade to this version (or revert to Xcode 3.2.6). This would allow us 
to
focus on supporting clang in the Xcode 4.x releases and encourage unification of
any clang specific changes to info files between the 10.4 and 10.6 trees. It 
also
will likely accelerate the elimination of the unstable tree in 10.4 as any clang
specific changes are backported into 10.4.
   Jack
--- fink-0.31.3/perlmod/Fink/PkgVersion.pm.orig 2011-10-20 14:46:20.0 
-0400
+++ fink-0.31.3/perlmod/Fink/PkgVersion.pm  2011-10-20 17:20:07.0 
-0400
@@ -4868,7 +4868,7 @@
 
 =item ensure_clang_prefix
 
-   my $prefix_path = ensure_clang_prefix;
+   my $prefix_path = ensure_clang_prefix $arch;
 
 Ensures that a path-prefix directory exists to use clang compilers
 Returns the path to the resulting directory.
@@ -4876,6 +4876,8 @@
 =cut
 
 sub ensure_clang_prefix {
+   my $arch = shift;
+
my $dir = "$basepath/var/lib/fink/path-prefix-clang";
unless (-d $dir) {
mkdir_p $dir or die "Path-prefix dir $dir cannot be created!\n";
@@ -4904,7 +4906,7 @@
 if [ "\$compiler" = "c++" -o "\$compiler" = "g++" ]; then
   compiler="clang++"
 fi
-exec \$compiler "\$@"
+exec \$compiler "-arch" "$arch" "\$@"
 EOF
close GPP;
chmod 0755, $gpp or die "Path-prefix file $gpp cannot be made 
executable!\n";
@@ -5227,15 +5229,22 @@
}
$pathprefix = ensure_gpp_prefix($vers);
}
-   if ($config->param("Distribution") eq "10.6" || 
$config->param("Architecture") eq "x86_64") {
-   # Use single-architecture compiler-wrapper on 10.6. Also
-   # override on older 10.x (gcc3.3 & 10.4T not supported)
-   $pathprefix = 
ensure_gpp106_prefix($config->param("Architecture"));
+   if (($config->param("Distribution") eq "10.6") || 
($config->param("Architecture") eq "x86_64")) {
+   my $link = readlink('/usr/bin/gcc');
+   if (($config->param("Distribution") eq "10.6") && 
($link eq "llvm-gcc-4.2")) {
+   # Use clang for gcc/g++ on darwin10 when Xcode 
4.2 or
+   # later is installed.
+   $pathprefix = 
ensure_clang_prefix($config->param("Architecture"));
+   } else {
+   # Use single-architecture compiler-wrapper on 
10.6. Also
+   # override on older 10.x (gcc3.3 & 10.4T not 
supported)
+   $pathprefix = 
ensure_gpp106_prefix($config->param("Architecture"));
+   }
}
if  ($config->param("Distribution") gt "10.6") {
# Use clang for gcc/g++ on darwin11 and later. Only
# x86_64 supported so can override single-arch wrappers.
-   $pathprefix = ensure_clang_prefix();
+   $pathprefix = 
ensure_clang_prefix($config->param("Architecture"));
}
$script_env{'PATH'} = "$pathprefix:" . $script_env{'PATH'};
}
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

   The ppl9.info file provides a good example of the adjustments we need to
make to info files in order to support path-prefix-clang under Xcode 4.2 on 
SL...

--- /sw/fink/10.6/stable/main/finkinfo/devel/ppl9.info  2011-09-26 
09:48:21.0 -0400
+++ ppl9.info   2011-10-20 18:44:37.0 -0400
@@ -1,6 +1,6 @@
 Package: ppl9
 Version: 0.11.2
-Revision: 2
+Revision: 3
 BuildDependsOnly: True
 Depends: <<
%N-shlibs (= %v-%r),
@@ -89,7 +89,7 @@
fi
# workaround llvm/clang's absence of -f rounding-math, 
# which caused test suite failures
-   if test "$darwin_vers" -ge 11 ; then
+if [ `gcc -v 2>&1 | grep -c clang` = "1" ]; then
  disable_fpmath="--disable-fpmath"
fi
../configure %c

where the conditional should be switched from testing the darwin release to 
checking the
default fink compiler in use instead.
 Jack
ps With the above change, ppl9 builds without regressions using 'fink -m' under 
Xcode 4.2's
clang on SL.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 10:06:24AM +0200, Martin Costabel wrote:
> On 21/10/11 01:05, Jack Howarth wrote:
> []
>> should upgrade to this version (or revert to Xcode 3.2.6). This would allow 
>> us to
>> focus on supporting clang in the Xcode 4.x releases and encourage 
>> unification of
>> any clang specific changes to info files between the 10.4 and 10.6 trees. It 
>> also
>> will likely accelerate the elimination of the unstable tree in 10.4 as any 
>> clang
>> specific changes are backported into 10.4.
>
> The most common "clang specific changes to info files" are currently
> SetCC: llvm-gcc-4.2
> SetCXX: llvm-g++
> because many packages won't compile with clang.
> This is not backportable.
>
> -- 
> Martin

Martin,
   I am baffled by your comment "This is not backportable.". For those packages 
which
aren't compatible with clang, we don't have to do anything at all. The presence 
of...

SetCC: llvm-gcc-4.2
SetCXX: llvm-g++

will override the path-prefix-clang just as it does in fink 10.7. The info file 
changes 
that I am referring to are those clang specific fixes which are currently made 
conditional by
the darwin version. These can be simply replaced by conditionals on the default
fink system compiler in use. Thus...

if test "$darwin_vers" -ge 11 ; then

...becomes...

if [ `gcc -v 2>&1 | grep -c clang` = "1" ]; then

and achieves the same effect. I really don't understand you resistance to 
extending
path-prefix-clang to SL when Xcode 4.2 is installed. The SL Xcode 4.2 
installation changes
the default system compiler to llvm-gcc which is an entirely untested 
configuration for the
fink package set. At least my patch for fink has the advantage of leveraging 
the changes
made for clang compatiblity in 10.7 and causes no problems for folks still on 
Xcode 3.2.x/4.0.x.
Leaving breakage in place isn't really a good approach for fink users.
   Jack
ps I have already built x86_64 fink 10.6 with clang through to pymol-py27 with 
only minor
info file corrections of the form above. Also, this is a chicken and the egg 
problem as well
since these minor info file corrections aren't going to be made until fink uses 
clang under
SL Xcode 4.2. We should just release a fink 0.31.4 with this feature and start 
making these
minor modes to the 10.4 info files.

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 10:06:24AM +0200, Martin Costabel wrote:
> On 21/10/11 01:05, Jack Howarth wrote:
> []
>> should upgrade to this version (or revert to Xcode 3.2.6). This would allow 
>> us to
>> focus on supporting clang in the Xcode 4.x releases and encourage 
>> unification of
>> any clang specific changes to info files between the 10.4 and 10.6 trees. It 
>> also
>> will likely accelerate the elimination of the unstable tree in 10.4 as any 
>> clang
>> specific changes are backported into 10.4.
>
> The most common "clang specific changes to info files" are currently
> SetCC: llvm-gcc-4.2
> SetCXX: llvm-g++
> because many packages won't compile with clang.
> This is not backportable.
>
> -- 
> Martin

Martin,
   Re-reading your response again, I assume you meant that the info files will 
never
been entirely unified. This is true however that shouldn't stand in our way of 
attempting
to make fink usable for SL users who have Xcode 4.2 installed. We really only 
have two
choices there...

1) Leave fink as is and manually check if each info file is miscompiled by 
llvm-gcc.
This is a lot of work for a smallish testing and developer group to deal with. 
It also
requires far more info file changes to switch these problem packages to clang 
or gcc-4.2.
2) Use my approach of enabling the path-prefix-clang on SL when Xcode 4.2 is 
detected via
the system compiler change. This gives us a well tested package set which 
already has been
checked against clang3.0svn.

Note that fink is currently badly broken under Xcode 4.2 on SL. The gmp/gmp5 
packages are
miscompiled and none of the gcc4x packages can bootstrap the FSF gcc compilers 
under llvm-gcc.
  Jack

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Xcode 4.2

[Jack Howarth]

behavior and allowing of some warnings
-  darwin_vers=`uname -r | cut -d. -f1`
-  if test "$darwin_vers" -ge 11 ; then
+  if [ `gcc -v 2>&1 | grep -c clang` = "1" ]; then
 export CFLAGS='-g -O3 -fwrapv'
 clang_configure_params="--disable-error-on-warning"
   fi

--- /sw/fink/10.6/stable/main/finkinfo/devel/ppl9.info  2011-09-26 
09:48:21.0 -0400
+++ ppl9.info   2011-10-20 18:44:37.0 -0400
@@ -1,6 +1,6 @@
 Package: ppl9
 Version: 0.11.2
-Revision: 2
+Revision: 3
 BuildDependsOnly: True
 Depends: <<
%N-shlibs (= %v-%r),
@@ -89,7 +89,7 @@
fi
# workaround llvm/clang's absence of -f rounding-math, 
# which caused test suite failures
-   if test "$darwin_vers" -ge 11 ; then
+if [ `gcc -v 2>&1 | grep -c clang` = "1" ]; then
  disable_fpmath="--disable-fpmath"
fi
../configure %c

--- /sw/fink/10.6/unstable/main/finkinfo/languages/python27.info
2011-07-12 14:07:34.0 -0400
+++ python27.info   2011-10-20 20:28:33.0 -0400
@@ -1,7 +1,7 @@
 Info2: <<
 Package: python%type_pkg[python]
 Version: 2.7.2
-Revision: 4
+Revision: 5
 Epoch: 1
 Type: python 2.7
 Maintainer: Daniel Johnson 
@@ -55,6 +55,8 @@
darwin_vers=`uname -r | cut -d. -f1`
if [ "$darwin_vers" = 11 ]; then
perl -pi -e 's/ -lSystemStubs//' ./configure
+   fi
+   if [ `gcc -v 2>&1 | grep -c clang` = "1" ]; then
perl -pi -e 's/-O3/-fwrapv -O3/' ./configure
fi
if [ "%m" = "x86_64" ]; then

Those changes for instance are sufficient to build pymol-py27 without 
regressions
under SL Xcode 4.2.
 Jack

> 
> On Oct 21, 2011, at 7:04 AM, Jack Howarth wrote:
> 
> > On Fri, Oct 21, 2011 at 10:06:24AM +0200, Martin Costabel wrote:
> >> On 21/10/11 01:05, Jack Howarth wrote:
> >> []
> >>> should upgrade to this version (or revert to Xcode 3.2.6). This would 
> >>> allow us to
> >>> focus on supporting clang in the Xcode 4.x releases and encourage 
> >>> unification of
> >>> any clang specific changes to info files between the 10.4 and 10.6 trees. 
> >>> It also
> >>> will likely accelerate the elimination of the unstable tree in 10.4 as 
> >>> any clang
> >>> specific changes are backported into 10.4.
> >> 
> >> The most common "clang specific changes to info files" are currently
> >> SetCC: llvm-gcc-4.2
> >> SetCXX: llvm-g++
> >> because many packages won't compile with clang.
> >> This is not backportable.
> >> 
> >> -- 
> >> Martin
> > 
> > Martin,
> >   Re-reading your response again, I assume you meant that the info files 
> > will never
> > been entirely unified. This is true however that shouldn't stand in our way 
> > of attempting
> > to make fink usable for SL users who have Xcode 4.2 installed. We really 
> > only have two
> > choices there...
> > 
> > 1) Leave fink as is and manually check if each info file is miscompiled by 
> > llvm-gcc.
> > This is a lot of work for a smallish testing and developer group to deal 
> > with. It also
> > requires far more info file changes to switch these problem packages to 
> > clang or gcc-4.2.
> > 2) Use my approach of enabling the path-prefix-clang on SL when Xcode 4.2 
> > is detected via
> > the system compiler change. This gives us a well tested package set which 
> > already has been
> > checked against clang3.0svn.
> > 
> > Note that fink is currently badly broken under Xcode 4.2 on SL. The 
> > gmp/gmp5 packages are
> > miscompiled and none of the gcc4x packages can bootstrap the FSF gcc 
> > compilers under llvm-gcc.
> >  Jack
> > 
> > --
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Cisco Self-Assessment and learn 
> > about Cisco certifications, training, and career opportunities. 
> > http://p.sf.net/sfu/cisco-dev2dev
> > ___
> > Fink-devel mailing list
> > Fink-devel@lists.sourceforge.net
> > List archive:
> > http://news.gmane.org/gmane.os.apple.fink.devel
> > Subscription management:
> > https://lists.sourceforge.net/lists/listinfo/fink-devel

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 09:01:58AM -0700, David R. Morrison wrote:
> 
> On Oct 21, 2011, at 8:50 AM, Jack Howarth wrote:
> 
> > On Fri, Oct 21, 2011 at 08:05:38AM -0700, David R. Morrison wrote:
> >> So at the very least, we should put a news item on the fink webpage 
> >> warning users that fink on 10.6 is currently incompatible with Xcode 4.2, 
> >> and suggesting a downgrade to Xcode 3.2.6.
> >> 
> >> Another short-term measure would be to put a test into fink to check for 
> >> Xcode 4.2 on 10.6, and warn users that they should downgrade.
> >> 
> >> The question of how and whether to adapt the fink 10.6 release to 
> >> accomodate this major change by apple is a more difficult one, and will 
> >> require additional thought as well as time to implement.
> >> 
> >>  -- Dave
> > 
> > Dave,
> >   The change as implemented on 
> > http://sourceforge.net/tracker/?func=detail&aid=3426897&group_id=17203&atid=317203
> > will be transparent to current Fink users who aren't on 10.6 with Xcode 
> > 4.2. The only change for Lion users will be
> > that the clang compiler wrappers will explictly pass the --arch x86_64 
> > (which again should be a transparent change
> > and cause no issues).
> >I been able to build...
> 
> 
> Lots of questions here, including:
> 1) Do things build differently?  One of our main design principles in fink is 
> that things should build the same for everybody.

I don't quite understand that question. Yes, we are switching the fink system 
compiler under SL Xcode 4.2 from
llvm-gcc to clang. However, the only alternative would be create a new 
path-prefix-gcc42 and force fink, under
SL Xcode 4.2, to use gcc-4.2 instead.

> 2) Any problem with mixing and matching, i.e., upgrading the compiler on an 
> already-installed fink?

There really shouldn't be an issue with that. If any are found, they should be 
considered Xcode bugs and
radar reports opened against them.

   I should expand on my main interest here. While clang is being tested well 
on fink 10.7 at x86_64, very little
testing occurs for i386 code generation under the clang compilers. Fink 
supporting path-prefix-clang under
SL Xcode 4.2 achieves the goal of unbreaking fink on the configuration while 
also providing a test bed for
discovering clang bugs in i386 code generation with GPLv3 software which Apple 
can't compile. Recent events
have proved the value of such a test bed. For example, David Fang recently 
reported breakage in libmpfr4-3.1.0
when built with clang from Lion Xcode 4.2. This turned out to be a previously 
unknown bug in darwin's new
tls support which is now enabled in the clang compiler under Xcode 4.2...

http://llvm.org/bugs/show_bug.cgi?id=1

I was able to use fink to generate a standalone test case for rader which 
allowed Apple to rapidly
fix the issue for the LLVM 3.0 release. Hopefully we will find similar issues 
under i386 fink built with
clang which can be addressed upstream.
 Jack
ps We should also not forget that using clang under SL Xcode 4.2 significantly 
shortens the average
package build time and should be view as another bonus.

> 
>   -- Dave
> 

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 09:01:58AM -0700, David R. Morrison wrote:
> 
> On Oct 21, 2011, at 8:50 AM, Jack Howarth wrote:
> 
> > On Fri, Oct 21, 2011 at 08:05:38AM -0700, David R. Morrison wrote:
> >> So at the very least, we should put a news item on the fink webpage 
> >> warning users that fink on 10.6 is currently incompatible with Xcode 4.2, 
> >> and suggesting a downgrade to Xcode 3.2.6.
> >> 
> >> Another short-term measure would be to put a test into fink to check for 
> >> Xcode 4.2 on 10.6, and warn users that they should downgrade.
> >> 
> >> The question of how and whether to adapt the fink 10.6 release to 
> >> accomodate this major change by apple is a more difficult one, and will 
> >> require additional thought as well as time to implement.
> >> 
> >>  -- Dave
> > 
> > Dave,
> >   The change as implemented on 
> > http://sourceforge.net/tracker/?func=detail&aid=3426897&group_id=17203&atid=317203
> > will be transparent to current Fink users who aren't on 10.6 with Xcode 
> > 4.2. The only change for Lion users will be
> > that the clang compiler wrappers will explictly pass the --arch x86_64 
> > (which again should be a transparent change
> > and cause no issues).
> >I been able to build...
> 
> 
> Lots of questions here, including:
> 1) Do things build differently?  One of our main design principles in fink is 
> that things should build the same for everybody.
> 2) Any problem with mixing and matching, i.e., upgrading the compiler on an 
> already-installed fink?
> 
>   -- Dave
> 

Dave,
   One other observation. Unlike previous common Xcode releases, we appear to 
be particularly
lucky with the quality of Xcode 4.2 on SL. Comparing the clang releases on SL 
and Lion...

Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.8.0
Thread model: posix

Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

...they both are based on the same LLVM release and even have the same tags. 
This strongly
suggests that there should be few omissions in the Xcode 4.2 SL release. So far 
I have found
no issues with building packages under clang from Xcode 4.2 on SL compared to 
Lion.
  Jack


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 09:01:58AM -0700, David R. Morrison wrote:
> 
> On Oct 21, 2011, at 8:50 AM, Jack Howarth wrote:
> 
> > On Fri, Oct 21, 2011 at 08:05:38AM -0700, David R. Morrison wrote:
> >> So at the very least, we should put a news item on the fink webpage 
> >> warning users that fink on 10.6 is currently incompatible with Xcode 4.2, 
> >> and suggesting a downgrade to Xcode 3.2.6.
> >> 
> >> Another short-term measure would be to put a test into fink to check for 
> >> Xcode 4.2 on 10.6, and warn users that they should downgrade.
> >> 
> >> The question of how and whether to adapt the fink 10.6 release to 
> >> accomodate this major change by apple is a more difficult one, and will 
> >> require additional thought as well as time to implement.
> >> 
> >>  -- Dave
> > 
> > Dave,
> >   The change as implemented on 
> > http://sourceforge.net/tracker/?func=detail&aid=3426897&group_id=17203&atid=317203
> > will be transparent to current Fink users who aren't on 10.6 with Xcode 
> > 4.2. The only change for Lion users will be
> > that the clang compiler wrappers will explictly pass the --arch x86_64 
> > (which again should be a transparent change
> > and cause no issues).
> >I been able to build...
> 
> 
> Lots of questions here, including:
> 1) Do things build differently?  One of our main design principles in fink is 
> that things should build the same for everybody.
> 2) Any problem with mixing and matching, i.e., upgrading the compiler on an 
> already-installed fink?
> 
>   -- Dave
> 

Dave,
   One other observation. As Apple indicated in my radar Problem ID: 9521882, 
"ocaml i386 linkage regression in Xcode 4.0.x",
this bug is fixed in Xcode 4.2 (as tested on SL). The ocaml-3.12.1-1 package 
now builds without linkage errors on i386 10.6 fink
using Xcode 4.2 with any compiler (clang, gcc-4.2 or llvm-gcc-4.2). Yet another 
reason to support the Xcode 4.2 release and
encourage folks to migrate off of Xcode 4.0.
   Jack


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 09:02:56PM +0200, Martin Costabel wrote:
> On 21/10/11 16:04 , Jack Howarth wrote:
>> On Fri, Oct 21, 2011 at 10:06:24AM +0200, Martin Costabel wrote:
>>> On 21/10/11 01:05, Jack Howarth wrote:
>>> []
>>>> should upgrade to this version (or revert to Xcode 3.2.6). This would 
>>>> allow us to
>>>> focus on supporting clang in the Xcode 4.x releases and encourage 
>>>> unification of
>>>> any clang specific changes to info files between the 10.4 and 10.6 trees. 
>>>> It also
>>>> will likely accelerate the elimination of the unstable tree in 10.4 as any 
>>>> clang
>>>> specific changes are backported into 10.4.
>>>
>>> The most common "clang specific changes to info files" are currently
>>> SetCC: llvm-gcc-4.2
>>> SetCXX: llvm-g++
>>> because many packages won't compile with clang.
>>> This is not backportable.
>
>> Martin,
>> Re-reading your response again, I assume you meant that the info files 
>> will never
>> been entirely unified. This is true however that shouldn't stand in our way 
>> of attempting
>> to make fink usable for SL users who have Xcode 4.2 installed. We really 
>> only have two
>> choices there...
>>
>> 1) Leave fink as is and manually check if each info file is miscompiled by 
>> llvm-gcc.
>> This is a lot of work for a smallish testing and developer group to deal 
>> with. It also
>> requires far more info file changes to switch these problem packages to 
>> clang or gcc-4.2.
>> 2) Use my approach of enabling the path-prefix-clang on SL when Xcode 4.2 is 
>> detected via
>> the system compiler change. This gives us a well tested package set which 
>> already has been
>> checked against clang3.0svn.
>
> What I mean is that a package that does not compile under clang needs to  
> include the above fix for xcode-4.2 if your automatic switch to clang is  
> implemented. But then it will probably no longer work on 10.5 and on  
> 10.6 with xcode-3.2. You would need one info file for xcode-4.2 and  
> another one for xcode<=3.2. I don't see how this is possible inside the  
> 10.4 tree.

I don't see why this has to be so complex. If you run into package that is 
incompatible with
clang, just use...

if [ `gcc -v 2>&1 | grep -c clang` = "1" ]; then
export CC=llvm-gcc-4.2
export CXX=llvm-g++-4.2
fi

We could create a path-prefix-gcc42 to force the SL Xcode 4.2 compilers under 
fink to use
gcc-4.2/g++-4.2 but that doesn't promote the general progress by encouraging 
testing of
i386 code generation from clang.

>
> -- 
> Martin

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 09:32:08PM +0200, Martin Costabel wrote:
> On 21/10/11 21:18 , Alexander Hansen wrote:
>
>> On 10/21/11 3:02 PM, Martin Costabel wrote:
> []
>>> What I mean is that a package that does not compile under clang
>>> needs to include the above fix for xcode-4.2 if your automatic
>>> switch to clang is implemented. But then it will probably no longer
>>> work on 10.5 and on 10.6 with xcode-3.2. You would need one info
>>> file for xcode-4.2 and another one for xcode<=3.2. I don't see how
>>> this is possible inside the 10.4 tree.
>>>
>>
>> I'm showing llvm-gcc-4.2 and llvm-g++ as part of Xcode 3.2.6 (actually
>> all the way back to 3.2.3 in my pkgutil history), so we're probably
>> not going to break things for people on 10.6 who have stayed current
>> with Xcode.
>
> Yes, it exists, but whether it works correctly is another question. It  
> would have to be tested.
>
>> 10.5, of course, is another matter.
>
> At least, this could be captured via the Distribution field and  
> duplication of info files. But there are lots of packages in the 10.4  
> tree for which the compatibility with clang is unknown because it hasn't  
> yet been tested.
>
> Is the possible benefit for a tiny minority of xcode-4.2 users on Snow  
> Leopard really worth all this hassle?

Considering that i386 fink represents the most testing clang will ever see
against GPLv3 software as a 32 bit compiler, I would say yes. Currently
fink is broken for Xcode 4.2 on SL. We have two ways to go. 

1) Backwards by implementing a path-prefix-gcc42 of gcc-4.2 based compiler
wrappers only to be used for 10.6 running llvm-gcc as the system compiler.

2) Forwards were we try to do some good for the community by testing
the clang compiler's i386 code generation.

I would argue that if we don't do 1) then 2) causes little harm. So what
if the package set if somewhat reduced initially. If the user wants the
full set, let them revert to Xcode 3.2.6. This option at least allows those
users who purchased Xcode 4 to leverage clang under SL.


>
> -- 
> Martin

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

   In view of the comments so far, the path of least resistance for fixing fink 
to
use SL Xcode 4.2 obviously appears to be reverting the system compiler under 
fink to gcc-4.2
and g++-4.2 for cc/gcc and c++/g++ respectively. The simple approach would be 
to enhance
the compiler wrapper for path-prefix-10.6 with something like...

--- PkgVersion.pm.orig  2011-10-21 17:54:49.0 -0400
+++ PkgVersion.pm   2011-10-21 19:08:12.0 -0400
@@ -4953,6 +4953,14 @@
 done
 IFS="\$save_IFS"
 export PATH="\$newpath"
+if [[ `/usr/bin/sw_vers -productVersion | cut -d'.' -f1-2` == 10.6 ]]; then
+  if [ \$compiler == "cc" ] || [ \$compiler == "gcc" ]; then
+ compiler="gcc-4.2"
+  fi
+  if [ \$compiler == "c++" ] || [ \$compiler == "g++" ]; then
+ compiler="g++-4.2"
+  fi
+fi
 exec \$compiler "-arch" "$arch" "\$@"
 EOF
close GPP;

so that on SL, gcc-4.2 and g++-4.2 are called directly instead of using
the cc/gcc and cxx/g++ symlinks. This approach would seem to be robust
and safe.
   Jack

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] odd compiler_wrapper glitch in fink bootstrap

[Jack Howarth]

   In an effort to implement the alternative fix of forcing SL to use gcc-4.2
for cc/gcc and g++-4.2 for c++/g++ in the path-prefix-10.6 compiler_wrapper,
I decided to test the fink patch...

--- PkgVersion.pm.orig  2011-10-20 14:46:20.0 -0400
+++ PkgVersion.pm   2011-10-22 11:04:44.0 -0400
@@ -4953,6 +4953,19 @@
 done
 IFS="\$save_IFS"
 export PATH="\$newpath"
+# use Apple gcc-4.2 compilers on SL
+case `uname -r` in
+10.*)
+case \$compiler in
+cc|gcc)
+compiler="gcc-4.2"
+;;
+c++|g++)
+compiler="g++-4.2"
+;;
+esac
+;;
+esac
 exec \$compiler "-arch" "$arch" "\$@"
 EOF
close GPP;

Oddly this change to the installed compiler_wrapper doesn't survive through
the bootstrap. If you watch /sw/var/lib/fink/path-prefix-10.6 carefully during
the bootstrap, you will see that immediately after the installation of fink,
the compiler_wrapper installed in /sw/var/lib/fink/path-prefix-10.6, contains
the expected change...

# use Apple gcc-4.2 compilers on SL
case `uname -r` in
10.*)
case $compiler in
cc|gcc)
compiler="gcc-4.2"
;;
c++|g++)
compiler="g++-4.2"
;;
esac
;;
esac

however shortly afterwards in the bootstrap, the compiler_wrapper is replaced 
with
one missing this change (from the toplevel compiler_wrapper.in I guess). It is 
odd
that we don't see this problem with the path-prefix-clang compiler_wrapper which
also differs from the top-level compiler_wrapper.in.
   Any ideas on how to suppress this second installation of the 
compiler_wrapper
and why are we doing that in the first place?
  Jack


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] alternative Xcode 4.2 fix for SL

[Jack Howarth]

   I have opened 
http://sourceforge.net/tracker/?func=detail&aid=3427243&group_id=17203&atid=317203
with an alternative patch for solving the system compiler change on SL under 
Xcode 4.2. The patch
uses...

diff -uNr fink-0.31.3/compiler_wrapper.in fink-0.31.3.new/compiler_wrapper.in
--- fink-0.31.3/compiler_wrapper.in 2010-01-09 18:47:01.0 -0500
+++ fink-0.31.3.new/compiler_wrapper.in 2011-10-22 11:43:14.0 -0400
@@ -11,6 +11,19 @@
 done
 IFS="$save_IFS"
 export PATH="$newpath"
+# use Apple gcc-4.2 compilers on SL
+case `uname -r` in
+10.*)
+case $compiler in
+cc|gcc)
+compiler="gcc-4.2"
+;;
+c++|g++)
+compiler="g++-4.2"
+;;
+esac
+;;
+esac
 exec $compiler -arch @ARCHITECTURE@ "$@"
 # strip path-prefix to avoid finding this wrapper again
 # @PREFIX@/bin is needed to pick up ccache-default
diff -uNr fink-0.31.3/perlmod/Fink/PkgVersion.pm 
fink-0.31.3.new/perlmod/Fink/PkgVersion.pm
--- fink-0.31.3/perlmod/Fink/PkgVersion.pm  2011-09-12 10:22:37.0 
-0400
+++ fink-0.31.3.new/perlmod/Fink/PkgVersion.pm  2011-10-22 11:04:44.0 
-0400
@@ -4953,6 +4953,19 @@
 done
 IFS="\$save_IFS"
 export PATH="\$newpath"
+# use Apple gcc-4.2 compilers on SL
+case `uname -r` in
+10.*)
+case \$compiler in
+cc|gcc)
+compiler="gcc-4.2"
+;;
+c++|g++)
+compiler="g++-4.2"
+;;
+esac
+;;
+esac
 exec \$compiler "-arch" "$arch" "\$@"
 EOF
close GPP;

to insure under SL that cc/gcc and c++/g++ always resolve to gcc-4.2 and 
g++-4.2. This change has
to exist in both perlmod/Fink/PkgVersion.pm as well as compiler_wrapper.in 
because setup.sh uses
the later to replace the copy first installed by PkgVersion.pm during the 
bootstrap. Tested on
x86_64 10.6 fink against Xcode 4.2 with the llvm-gcc incompatible builds of 
gmp5 and gcc46.
 Once we fix this issue in fink, we also ought to start recommending Xcode 
4.0 users update
to Xcode 4.2. There are a number of Xcode 4.0 bugs fixed in 4.2 including the 
i386 ocaml build
problem.
Jack
ps Benchmarking shows that the additional code in the compiler_wrapper only 
adds 1 msec to the
execution time and that using 'uname -r' is twice as fast as using sw_vers to 
check the OS release.


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Xcode 4.2

[Jack Howarth]

On Fri, Oct 21, 2011 at 09:01:58AM -0700, David R. Morrison wrote:
> 
> On Oct 21, 2011, at 8:50 AM, Jack Howarth wrote:
> 
> > On Fri, Oct 21, 2011 at 08:05:38AM -0700, David R. Morrison wrote:
> >> So at the very least, we should put a news item on the fink webpage 
> >> warning users that fink on 10.6 is currently incompatible with Xcode 4.2, 
> >> and suggesting a downgrade to Xcode 3.2.6.
> >> 
> >> Another short-term measure would be to put a test into fink to check for 
> >> Xcode 4.2 on 10.6, and warn users that they should downgrade.
> >> 
> >> The question of how and whether to adapt the fink 10.6 release to 
> >> accomodate this major change by apple is a more difficult one, and will 
> >> require additional thought as well as time to implement.
> >> 
> >>  -- Dave
> > 
> > Dave,
> >   The change as implemented on 
> > http://sourceforge.net/tracker/?func=detail&aid=3426897&group_id=17203&atid=317203
> > will be transparent to current Fink users who aren't on 10.6 with Xcode 
> > 4.2. The only change for Lion users will be
> > that the clang compiler wrappers will explictly pass the --arch x86_64 
> > (which again should be a transparent change
> > and cause no issues).
> >I been able to build...
> 
> 
> Lots of questions here, including:
> 1) Do things build differently?  One of our main design principles in fink is 
> that things should build the same for everybody.
> 2) Any problem with mixing and matching, i.e., upgrading the compiler on an 
> already-installed fink?
> 
>   -- Dave

Dave,
  Any thoughts on the alternative approach as implemented in...

http://sourceforge.net/tracker/?func=detail&aid=3427243&group_id=17203&atid=317203

Checking for 10.6 in the path-prefix-10.6 compiler-wrapper and substituting 
gcc-4.2 and g++-4.2
for instances of cc/gcc and c++/g++ seems the least invasive approach. 
Hopefully we can fix this
issue in the near term.
   Jack
ps It is unfortunate that we can't offer clang support to SL users but without 
a blanket adoption of 
clang for SL Xcode 4.2, I don't see the user base being big enough to merit the 
changes for a UseClang
option.

> 

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] SetCFLAGS: -g -O2 -std=c89

[Jack Howarth]

Brendan,
   I noticed you reverted gnupg2 in 10.7 to build against llvm-gcc with the
comment...

# stdint.h strangeness with clang

Have you tried the approach of using...

SetCFLAGS: -g -O2 -std=c89

with clang in gnupg2.info as is done for gnupg.info in 10.7? I suspect this may
clean up your issues with clang (which defaults to -std=c99).
   Jack

--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] enable path-prefix-clang for SL Xcode 4.2

[Jack Howarth]

On Wed, Nov 16, 2011 at 10:52:41AM -0500, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 10/21/11 6:09 PM, Max Horn wrote:
> > Jack,
> > 
> > Am 21.10.2011 um 21:53 schrieb Jack Howarth:
> > 
> >> On Fri, Oct 21, 2011 at 09:32:08PM +0200, Martin Costabel wrote:
> > 
> > [...]
> > 
> >>> Is the possible benefit for a tiny minority of xcode-4.2 users
> >>> on Snow Leopard really worth all this hassle?
> >> 
> >> Considering that i386 fink represents the most testing clang will
> >> ever see against GPLv3 software as a 32 bit compiler, I would say
> >> yes.
> > 
> > Worth it for *whom*, though? As I see it, this does *not* benefit
> > for the Fink project. It may be a benefit for the clang team; or
> > maybe for people who are interested in using clang for its own
> > good. While these may be noble goals, I think it is misleading to
> > claim that these benefit *Fink*. So let's drop that particular item
> > from the discussion -- it is noble, but irrelevant.
> > 
> > We have very limited resources, and I don't think we can afford to
> > squander them on things purely based on noble intentions. If it
> > turns out that going the "clang path" is the most effective for us
> > (has best ratio of effort to user experience or so), we should
> > consider it, but *only* for that reason.
> > 
> >> Currently fink is broken for Xcode 4.2 on SL. We have two ways to
> >> go.
> >> 
> >> 1) Backwards by implementing a path-prefix-gcc42 of gcc-4.2 based
> >> compiler wrappers only to be used for 10.6 running llvm-gcc as
> >> the system compiler.
> > 
> > This sounds more appealing to me than trying to check several
> > thousand packages for whether they compile with clang, and whether
> > clang compiles them correctly.
> > 
> >> 
> >> 2) Forwards were we try to do some good for the community by
> >> testing the clang compiler's i386 code generation.
> >> 
> >> I would argue that if we don't do 1) then 2) causes little harm.
> >> So what if the package set if somewhat reduced initially. If the
> >> user wants the full set, let them revert to Xcode 3.2.6. This
> >> option at least allows those users who purchased Xcode 4 to
> >> leverage clang under SL.
> > 
> > Actually, I think telling users to revert to Xcode 3.2.6 is a
> > rather lame excuse... I know a lot of people in academia who would
> > consider this a reason to switch away from Fink to MacPorts, Brew
> > or just hand-installing software...
> > 
> > So personally, I'd love to avoid that and get things compatible
> > with XCode 4.2 by making sure everything gets to use GCC 4.2 by
> > default.
> > 
> > 
> > Cheers, Max
> 
> Did we actually _confirm_ that Xcode 4.2 comes with gcc-4.2 on 10.6?
> We've got a user in IRC today who doesn't have it on a fresh install,
> and Alexander Strange is confident that Xcode 4.2 doesn't ship with
> gcc-4.2 even on 10.6.
> 
> I don't have the ability to confirm this for myself, so it would be
> nice if someone could check.  I _do_ know that the
> "uninstall-devtools" script left gcc-4.2 untouched on my Lion install,
> so it _looked_ like Xcode 4.2 had it.

Alexander,
On my both my Lion machine (which was updated from Xcode 4.1 to 4.2)
and my Snow Leopard machine (which was updated from Xcode 3.2.6 to 4.2)
I see a residual binary for gcc-4.2 in /usr/bin. However, on the Lion machine
there isn't a copy in /Developer/usr/bin. The same is true for my Snow Leopard
machine except that a copy does still exist in /Developer-3.2.6/usr/bin.

The various copies appear as...

/usr/bin/gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/gcc/gcc-5666.3~278/src/configure 
--disable-checking --enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib 
--build=i686-apple-darwin11 --program-prefix=i686-apple-darwin11- 
--host=x86_64-apple-darwin11 --target=i686-apple-darwin11 
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)

for Lion and

/usr/bin/gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking 
--enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib 
--build=i686-apple-darwin

Re: [Fink-devel] Compiler mess on Lion (Was Re: libgeos problem)

[Jack Howarth]

On Mon, Nov 28, 2011 at 09:42:44AM +0100, Martin Costabel wrote:
> On 27/11/11 21:50, Alexander Hansen wrote:
> []
>> We should probably do an apple-gcc-4.2 package, then. It might even be
>> handy on 10.7.
>
> If it builds on 10.7, I am all for it.
>
> I have been trying to build the scribus package on Lion, without success:
>
> - With clang, it runs into a clang bug that was detected a year ago
> 
> and has been fixed in the clang sources some time ago, but is still  
> present in current xcode-4.2.1.

Martin,
   Considering that llvm/clang 3.0 will be released shortly a better option
might be to BuildDepends on llvm30 once it is added to fink and use those
clang compilers.

>
> - With llvm-gcc42, the compiler goes into an infinite loop (100% cpu,  
> runs for hours without doing anything).
>
> (If anyone has the ear of an Apple employee, would you please box or  
> twist it violently, for giving us an operating system version whose  
> compilers have serious - and known - bugs)

Unfortunately, I really doubt we will see many fixes applied to
Apple's llvm-gcc. They have based it on an older llvm release which means 
any fixes will have to be backported (and their general concept is
to avoid non-essential fixes when clang works). Using llvm.org's
clang in these problem cases and pinging Apple to backport those
fixes to their current clang compiler is far more likely to be
successful.

>
> - With Fink's gcc-fsf-4.6, building fails already at the (cmake-)  
> configure stage, because cmake insists on placing a "-arch x86_64" flag  
> on the compiler line that makes gcc46 error out. And as usual with  
> cmake, it is impossible to find out where this flag comes from and how  
> to remove it.
>
> Why doesn't our gcc46 simply ignore the "-arch" flag instead of giving  
> an error?

File an upstream PR against FSF gcc if you want that enhancement. IMHO,
the compiler might as well error to provide a clear notice to the user
that their use of -arch won't be honored.

>
> These problems have also been detected by macports
> 
> In that bug ticket, one finds the remark
> "gcc42 does not build for Lion. No viable workaround."
>
> I don't know if this means that their apple-gcc42 does not build on  
> Lion, or that scribus doesn't even build with that compiler either.

I'd rather avoid the apple-gcc42 approach if possible since Apple seems
unlikely to continue to provide fixes to their gcc-4.2 sources for later
Xcode releases. I can well imagine that that this will cause issues
later on. It would be far better to use clang from llvm30 if possible.
Jack
ps I have been doing regular builds of llvm 3.0 and its works well under
Lion. Also major progress has been made in allowing dragonegg to provide
full support for vectorization using -msse4 
-fplugin-arg-dragonegg-enable-gcc-optzns.

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044091.html


`
>
> Note: This version of scribus builds OK on 10.5 and 10.6/pre-xcode-4.2.
>
> -- 
> Martin
>
>
>
>

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Apple clang issues vs Xcode 4.3

[Jack Howarth]

   Since Xcode 4.3 is rumored for iOS 5.1's release, it might be worthwhile if 
we
tried to identify instances in the fink package set where Apple's clang from 
Xcode 4.1/4.2
fails but clang from llvm 3.0 succeeds. Filing radar reports with test cases 
for those
cases might help get some of these fixes backported for Xcode 4.3's release.
 Jack

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] openmpi-dev

[Jack Howarth]

On Thu, Dec 01, 2011 at 09:17:48PM +0100, Benjamin Chagot wrote:
> Thank you for your quick answer.
> As I had a trouble with dependency resolving I though openmpi-dev wasn't  
> released.

Benjamin,
   That shouldn't be happening since 10.7 never had openmpi-dev. I assume you
were trying to build fftw-openmpi-mpi which apparently wasn't adjusted for
the refactored openmpi package. I should be BuildDepend'ing on openmpi
rather than openmpi-dev for 10.7.
 Jack

>
> Thanks anyway,
>
> Benjamin
>
> Le 01/12/11 19:58, Jack Howarth a écrit :
>> On Thu, Dec 01, 2011 at 06:41:51PM +0100, Benjamin Chagot wrote:
>>> Dear Jack Howarth,
>>>
>>> I am a user of fink under macosx Lion OS. I was trying to install
>>> openmpi-dev and it appears that this package has not been updated for
>>> Lion yet.
>>> Are you are willing to do so ?
>> Benjamin,
>> The openmpi package has existed in the 10.7 tree since Lion's release.
>> Note that the package was re-factored and no longer has a openmpi-dev
>> split-off. This was done because the alternative lammpi MPI has been
>> depreciated from 10.7 so openmpi doesn't have to co-exist with it. Also
>> the openmpi in 10.7 was updated to the latest 1.5.3 release. Since having
>> two major releases of openmpi co-existing is extremely difficult due to
>> the number of overlapping files, fink 10.4/10.5/10.6 was left on the
>> older release and 10.7 was standardized on the newer release.
>>   Jack
>>
>>> And many thanks for the other packages I am using and that you are
>>> maintening for Fink.
>>>
>>> Cordially,
>>>
>>> Benjamin Chagot

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] openmpi-dev

[Jack Howarth]

On Thu, Dec 01, 2011 at 04:02:32PM -0500, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 12/1/11 3:41 PM, Jack Howarth wrote:
> > On Thu, Dec 01, 2011 at 09:17:48PM +0100, Benjamin Chagot wrote:
> >> Thank you for your quick answer. As I had a trouble with
> >> dependency resolving I though openmpi-dev wasn't released.
> > 
> > Benjamin, That shouldn't be happening since 10.7 never had
> > openmpi-dev. I assume you were trying to build fftw-openmpi-mpi
> > which apparently wasn't adjusted for the refactored openmpi
> > package. I should be BuildDepend'ing on openmpi rather than
> > openmpi-dev for 10.7. Jack
> > 
> >> 
> >> Thanks anyway,
> >> 
> >> Benjamin
> >> 
> 
> Indeed, that was the case.  fftw-mpi has been fixed now.

Actually none of the -mpi packages in 10.7 should have variants now
since there is only one mpi package present in 10.7.

> 
> 
> - -- 
> Alexander Hansen, Ph.D.
> Fink User Liaison
> http://finkakh.wordpress.com/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk7X62gACgkQB8UpO3rKjQ+kzwCfQ/Xn1UK+ItAOom6kSfRE7BJq
> CrQAoJ1MiA0ZS0Vlnin1Y6wC8LRA/Yre
> =feJP
> -END PGP SIGNATURE-

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] Compiler mess on Lion (Was Re: libgeos problem)

[Jack Howarth]

On Fri, Dec 02, 2011 at 09:59:31PM +0100, Martin Costabel wrote:
> On 28/11/11 15:54, Jack Howarth wrote:
>> On Mon, Nov 28, 2011 at 09:42:44AM +0100, Martin Costabel wrote:
> []
>>> I have been trying to build the scribus package on Lion, without success:
>>>
>>> - With clang, it runs into a clang bug that was detected a year ago
>>> <http://lists.cs.uiuc.edu/pipermail/llvmbugs/2010-November/015821.html>
>>> and has been fixed in the clang sources some time ago, but is still
>>> present in current xcode-4.2.1.
>>
>> Martin,
>> Considering that llvm/clang 3.0 will be released shortly a better option
>> might be to BuildDepends on llvm30 once it is added to fink and use those
>> clang compilers.
>
> I installed llvm30 from your new package on the submission tracker. No  
> problem installing.
>
> Unfortunately, the fatal bug is still there: Building scribus with the  
> new clang fails exactly as with /usr/bin/clang:
>
> In file included from  
> /sw/src/fink.build/scribus-x11-1.4.0-72.rc6/scribus-1.4.0.rc6/scribus/desaxe/digester.cpp:20:
 
> /sw/src/fink.build/scribus-x11-1.4.0-72.rc6/scribus-1.4.0.rc6/scribus/desaxe/actions.h:160:45:
>  
> error: 'body' is a private member of 'desaxe::Action'
> return  
> static_cast*>(body)->eval(dig, tag, attr);
>   ^
 
> /sw/src/fink.build/scribus-x11-1.4.0-72.rc6/scribus-1.4.0.rc6/scribus/desaxe/actions.h:101:15:
>  
> note: declared private here
> Action_body* body;
>  ^
> From the llvm bug system, I got the impression that this was fixed by  
> now. In fact, svn r141515 was supposed to fix it. For scribus, it didn't.
>
> I find still no way to build scribus on Lion.

I would suggest opening a PR on http://llvm.org/bugs/ against clang and attach 
the preprocessed
source obtained with --save-temps for the failing compilation. This may be a 
corner-case not
covered by r141515.
  Jack

>
> -- 
> Martin

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] avoid Xcode 4.3

[Jack Howarth]

  I would avoid Xcode 4.3 like the plague at the moment. The installation
via the App Store over Xcode 4.2.1 leaves the prior broken and the new
release unable to install its Command Line Tools (which are no longer installed
by default). I was forced to deinstall the Xcode 4.2.1 release with the
deinstallation scripts in order to allow Xcode 4.3 to download its own
command line tools. However, despite the command line tools installation
claiming to be successful, I can see no evidence of them in /Developer.
What a mess.
  Jack


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Xcode 4.3 installer glitch

[Jack Howarth]

   I've confirmed with both a clean install of Lion/Xcode 4.3/Command Line
Tools as well as an upgrade install of Xcode 4.3/Command Line Tools
over Xcode 4.2.1 that the installations fail to set the developer directory
path. In both cases, executing 'xcodebuild -version' produces the error 
message...

Error: No developer directory found at /Developer. Run /usr/bin/xcode-select to 
update the developer directory path.

until the user explicitly executes...

sudo xcode-select -switch /Applications/Xcode.app

We should probably put a note on the finkproject home page that
after installing Xcode 4.3, the Command Line Tools must be
manually installed (either from within Xcode 4.3 or from the
downloaded Command Line Tools installer on connect.apple.com)
and the developer directory path set with xcode-select as
above.
Jack
ps I filed this issue as radr:10881681, "Installing Xcode 4.3 command tools 
doesn't set developer directory path".

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] Xcode 4.3 c++ symlink

[Jack Howarth]

   I just noticed that executing the missing...

sudo xcode-select -switch /Applications/Xcode.app

on the Xcode 4.3 upgrade (followed by Command Line Tools
installation) from Xcode 4.2.1, resets the c++ symlink
from llvm-g++-4.2 to the expected clang++. Hopefully Apple
can upgrade the Command Line Tools installer to properly
set the developer directory path as part of he postinst
scripts.
   Jack

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] fixing developer directory path in fink?

[Jack Howarth]

It might be a reasonable idea to add a few lines of code to fink that
checks for an unset developer directory path. I believe all recent Xcode
releases have been setting this path so only Xcode 4.3 would result in
'xcodebuild -version' producing the error...

Error: No developer directory found at /Developer. Run /usr/bin/xcode-select to 
update the developer
directory path.

We could either have fink error out with a message that the user needs to 
execute...

sudo xcode-select -switch /Applications/Xcode.app

or assume that the user must be on Xcode 4.3 or later and execute that command 
for them.
Since I have observed that the /usr/bin/c++ symlink can be left set to 
llvm-g++-4.2
when the developer directory path is unset, I worry what other obscure issues 
could
exist as well in that case.
   Jack

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Re: [Fink-devel] fixing developer directory path in fink?

[Jack Howarth]

On Fri, Feb 17, 2012 at 11:00:34AM -0500, Alexander Hansen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 2/17/12 10:04 AM, Jack Howarth wrote:
> > It might be a reasonable idea to add a few lines of code to fink 
> > that checks for an unset developer directory path. I believe all 
> > recent Xcode releases have been setting this path so only Xcode
> > 4.3 would result in 'xcodebuild -version' producing the error...
> > 
> > Error: No developer directory found at /Developer. Run 
> > /usr/bin/xcode-select to update the developer directory path.
> > 
> > We could either have fink error out with a message that the user 
> > needs to execute...
> > 
> > sudo xcode-select -switch /Applications/Xcode.app
> > 
> > or assume that the user must be on Xcode 4.3 or later and execute 
> > that command for them. Since I have observed that the /usr/bin/c++ 
> > symlink can be left set to llvm-g++-4.2 when the developer 
> > directory path is unset, I worry what other obscure issues could 
> > exist as well in that case. Jack
> > 
> 
> For what it's worth, "xcodebuild -version" is only used in the
> bootstrap script, and there only to check whether Xcode's version is
> within the allowable limits for the OS version.  Everywhere else in
> fink VirtPackage.pm is used, and that has been updated for fink-0.32.3 .
> 
> I wouldn't think that /usr/bin/c++ still pointing to llvm-g++-4.2
> should really matter, since we've gone to all of the trouble to
> circumvent it with the path-prefix-clang wrappers.  "c++" is still
> "clang++" by default for Fink builds on 10.7.

I've only tested it once, but I am pretty sure when I did the Xcode 4.3
installation over Xcode 4.2.1 followed by the Command Line Tools 
installation (but not setting the developer directory path with
xcode-select), that the files sizes in /usr/bin and 
/Applications/Xcode.app/Contents/Developer/usr/bin
differed. I think it is worthwhile to make sure the user is really 
running the Xcode version that they think they are.

> 
> If anything, I'd worry more about packages that _don't_ work with
> clang that suddenly find themselves trying to build with it, due to a
> maintainer using e.g. SetCC: /usr/bin/gcc

My understanding from the Apple developers is that /usr/bin/gcc and /usr/bin/g++
will always be kept pointing at llvm-gcc-4.2 and llvm-g++-4.2 (at least while
they exist in Xcode).
 Jack
> 
> - -- 
> Alexander Hansen, Ph.D.
> Fink User Liaison
> http://finkakh.wordpress.com/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk8+eaIACgkQB8UpO3rKjQ/mGQCfSK1gLI92bynl0OCO5pu5TV7T
> X4cAn3HsD+SbGCFaKNqiNg+6U/lSjYlV
> =/AnR
> -END PGP SIGNATURE-

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

[Fink-devel] dyld: lazy symbol binding failed: Symbol not found: _Perl_Gthr_key_ptr

[Jack Howarth]

   While doing a clean bootstrap of fink 0.32.3 under Xcode 4.3, I am
seeing a postinstall failure during the installation of xml-sax-expat-pm5123 to
satisfy the build dependencies for relax-py27.

/sw/bin/dpkg-lockwait -i 
/sw/fink/dists/stable/main/binary-darwin-x86_64/libs/perlmods/xml-sax-expat-pm5123_0.40-4_darwin-x86_64.deb
(Reading database ... 50986 files and directories currently installed.)
Preparing to replace xml-sax-expat-pm5123 0.40-4 (using 
.../xml-sax-expat-pm5123_0.40-4_darwin-x86_64.deb) ...
Unpacking replacement xml-sax-expat-pm5123 ...
Setting up xml-sax-expat-pm5123 (0.40-4) ...
update-perl5123-sax-parsers: adding Perl SAX parser module info file of 
XML::SAX::Expat...
dyld: lazy symbol binding failed: Symbol not found: _Perl_Gthr_key_ptr
  Referenced from: 
/sw/lib/perl5/5.12.3/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle
  Expected in: flat namespace

dyld: Symbol not found: _Perl_Gthr_key_ptr
  Referenced from: 
/sw/lib/perl5/5.12.3/darwin-thread-multi-2level/auto/XML/Parser/Expat/Expat.bundle
  Expected in: flat namespace

/sw/var/lib/dpkg/info/xml-sax-expat-pm5123.postinst: line 6: 56511 Trace/BPT 
trap: 5   /sw/sbin/update-perl5123-sax-parsers --add XML::SAX::Expat
/sw/bin/dpkg: error processing xml-sax-expat-pm5123 (--install):
 subprocess post-installation script returned error exit status 133
Errors were encountered while processing:
 xml-sax-expat-pm5123
### execution of /sw/bin/dpkg-lockwait failed, exit code 1

Is anyone else seeing this issue and is there a workaround?
  Jack

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel