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-1
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
---
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
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 w
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
soversi
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
>>
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
>>
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 ju
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
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 enou
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.
> >
> >
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 post
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
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 is
gestion 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, Jac
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
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=
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
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
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 b
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
u
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 pp
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 Malwar
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
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.
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 fail
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 th
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
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-
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 l
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 re
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
h 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
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-projec
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-projec
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 sup
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
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 beha
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 the
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
> package
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
-compati
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;
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.
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 i
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
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 wit
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 bo
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 fi
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
Architect
) 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 t
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
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...
>&g
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 th
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 ch
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 pym
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
co
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 fin
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
packag
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
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 b
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-gc
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 ut
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
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
;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
>>&g
ecific 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 po
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
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
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
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
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
e 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
So
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://llv
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). For
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
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
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
+ 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
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
>
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
>
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
>
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 v
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
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-p
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.000
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.3
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
>
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 issu
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, 20
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 packa
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 f
ere 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 écri
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 answ
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:
>>>
&g
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
de
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
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
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
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 d
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
1 - 100 of 1300 matches
Mail list logo
