Martin,
I see the same error building g77 on my Powermac dual G5. I have
Darwin 6.8.5 installed (still waiting on my copy of Panther). This
is with the 10.2-gcc3 fink rsync and using the Aug 2003 gcc-3.3
updater from connect.apple.com.
One other question. Does anyone with g77 3.4 compiled
Blair,
It appears that the failures of building g77 are only
happening on G5 powermacs. I looked over the gcc testsuite
mailing list but it doesn't look as if any builds are being
done with G5's yet.
Jack
---
This SF.net
I have determined (as mentioned in my message on fink-users) that
the build failures under Darwin 6.8.5 on my G5 of the most current g77 3.4
package is due entirely to fink itself. If I disable fink and build
manually there are no problems and after sourcing fink, a make check-g77
of that
I may be dim here but I can't figure out how to
do the following under the Darwin linker. I have some
code that be linked against the static versions of a
library and on linux can easily do this by passing the
compiler...
-Xlinker -Bstatic $(PYTHON_LDFLAGS) -Xlinker -Bdynamic
which causes
Jeff,
You may want to grab a newer snapshot of gcc 3.4 and release another
g77 release to get the new -minsert-sched-nops support that IBM added...
http://gcc.gnu.org/ml/gcc/2003-11/msg01233.html
From reading Apple's G5 performance tech note (TN2086) it could
prevent some significant
Jeffrey,
Have you tried updating the g77 package to a more recent
snapshot. I seem to be see a huge number of new failures when
I try the 20031126 snapshot...
=== g77 tests ===
Schedule of variations:
unix
Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp
David,
Have you had any luck yet with the pymol-0.93 package that
Scott posted? Did you try moving aside your current /sw and
reinstalling fink 10.3? Also have you tried another machine?
Jack
ps If anyone else has had problems using Scott's posted pymol
info/patch files could
The current build of lammpi 7.0.6-10 in unstable is flawed in
that it creates a hybrid mix of shared and static libs rather than
a complete set of one or the other. I fixed this locally by appending
--enable-shared
to the ConfigureParams. This change allowed me to build a shared lib
version
I am trying to create a -mpi variant of the fftw package using the
Type field. I have managed to create a fftw.info that will build either
fftw/fftw-shlibs or fftw-mpi/fftw-mpi-shlibs depending on what (fftw
or fftw-mpi) is passed to 'fink install'. However am baffled on what
options I have to
Daniel,
I have only tested this on one machine but it seems the current fink
in 10.3 (0.21.2-1) breaks upgrading fftw/fftw-shlibs to fink-mpi/
fink-mpi-shlibs with the following comands...
fink install fftw
fink install fftw-mpi
Now the installation of fftw-mpi fails with...
/usr/bin/sudo
Daniel,
You might want to take a look at how fink currently handles Provides.
As I mentioned before, I had to create a new revision of fftw (2.1.5-6)
because the addition of Provides: fftw to both the fftw and fftw-mpi as
well as Provides: fftw-shlibs to both the fftw-shlibs and
Dave,
Could you look at the current fftw.info and grace.info in unstable
and make some suggestions? The problem that the Provides was meant to
solve was the following. If one does fink install grace it will
automatically install fftw. However without the Provides: fftw-shlibs
added to
Dave,
Can you clarify this a little more? I don't quite see where the
breakage will occur if I use Provides: fftw-shlibs in the main fftw
package which contains the headers. For example, I did...
fink install gromacs (picking fftw)
fink install gromacs-mpi (which installed fftw-mpi)
Then
Martin,
Has anyone documented a few of these g++ problems and brought
them up on the darwin-development mailing list at Apple? I have
found that the Apple devtool programmers that monitor that list
can often be quite helpful. At the very least, it will bring these
problems to their attention
Martin,
Just a stab in the dark, but have you considered trying to rebuild
octave with -fssa and -fssa-dce? Perhaps using the experimental dead
code elimination will work around the missing symbols.
Jack
---
SF.Net
Daniel,
William Scott just pointed out that fftw now creates shared libs
with dependencies into /sw/src.
otool -L /sw/lib/libdfftw.2.dylib
/sw/lib/libdfftw.2.dylib:
/sw/src/root-fftw-mpi-2.1.5-6/sw/lib/libdfftw.2.dylib (compatibility version
3.0.0, current version 3.7.0)
Peter,
I am using the libtool from Xcode 1.5. Unfortunately I don't
see a way to tell what version that libtool is. Perhaps if a
package needs to use ''make install prefix=%i', it should have
an explicit BuildDepends on a specific libtool from fink devel?
Jack
Martin,
I was able to fix this by moving the '--infodir=%p/share/info'
into ConfigureParams and changing any occurances of...
make install prefix=%i infodir=%i/share/info
...into...
make install DESTDIR=%d
With those changes, sent to the maintainer, I find that the
linkage problem
Peter,
Perhaps the fink packaging manual should be corrected to
be more explicit about this problem. It should probably state
clearly that make install DESTDIR=%d is the perferred form
of installation (compared to using make install prefix=%i)
whenever possible.
Jack
Daniel,
I have updated the freeglut packaging for the proposed freeglut package.
I have now verified that it is in fact a binary compatible drop-in replacement
for glut. I am able to have glut/glut-shlibs/molmol/gopenmol installed
and upgrade to freeglut/freeglut-shlibs without any binary
I have had my proposed freeglut packaging in tracker for
awhile now and there has been no further comments even though
it is still marked as undergoing evaluation.
https://sourceforge.net/tracker/?func=detailatid=414256aid=1017330group_id=17203
Is there any particular problems with this
Michal,
I have been told that the compatibility version is rather arbitrary
and that is a non-issue. All the major Linux distros have adopted
freeglut since it is trully open source and, more importantly, actively
maintained. As for rbogl, I would suggest you file a bug report with
the form
Apple has released the November 2004 gcc 3.3 update on
connect.apple.com today. This updater fixes the c++ compiler
issues that have been plaguing fink.
Jack
---
This SF.Net email is sponsored by: InterSystems CACHE
FREE
In testing some builds of the APBS Adpative Poisson-Boltzmann Solver
package under fink, I noticed that the g95 compiler currently in 10.3
unstable builds a usable version of apbs. However I was shocked at how
much of a performance regression there was from g77. APBS runs almost
60% slower
Dan,
I noticed your messages about the freeglut packaging being broken.
With the 10.4 branch being created, I think now is a good time to address
this issue. Since glut and freeglut are not really binary replacements
it should be decided whether freeglut should replace the glut package in
the
Dan,
I think we should follow Debian's lead here. They are in the process
of depreciating out their libglut3 package in favor of freeglut. They have
replaced their old libglut3 package, based on the old non-free version, with
a dummy package that depends on freeglut as a transitional
Dan,
I believe the following versions of freeglut.info and glut.info are
close to what we need for 10.4
Package: freeglut
Version: 2.2.0
Revision: 2
GCC: 3.3
Maintainer: Jack Howarth [EMAIL PROTECTED]
Source
://freeglut.sourceforge.net/
-
Package: glut
Version: 3.7
Revision: 25
GCC: 3.3
Maintainer: Jack Howarth [EMAIL PROTECTED]
Source: None
Depends: freeglut
BuildDepends: fink (= 0.9.9)
BuildDependsOnly: True
PatchScript:
CompileScript
Dan,
What if we patch the freeglut package to build with a different
shared lib version number? I think this is the main source of the
confusion out there. The developers of freeglut let it create a
libglut.3.x.x.so/dylib when it should have been bumped up to
libglut.4.x.x.so/dylib or such
Chris,
Well I did a quick test of changing the versioning and that doesn't help
much under fink anyway. If I use...
Package: freeglut
Version: 2.2.0
Revision: 2
GCC: 3.3
Maintainer: Jack Howarth howarth at bromo.med.uc.edu
Source: mirror:sourceforge:freeglut/%N-%v.tar.gz
Source-MD5
Chris,
I've tried a test build of the current glut package where I have
the following packaging...
...for the glut package...
-rwxr-xr-x 1 root admin 744232 17 Apr 15:56 /sw/lib/glut/libglut.a
lrwxr-xr-x 1 root admin 14 17 Apr 15:56 /sw/lib/libglut.a - glut/libglut.a
lrwxr-xr-x 1 root
and the debs they create all pass fink validate.
--
Package: glut
Version: 3.7
Revision: 24
GCC: 3.3
Maintainer: Jack Howarth [EMAIL PROTECTED]
Source: http://www.opengl.org/developers/documentation/%N/%N-%v.tar.gz
Source-MD5
Martin,
I didn't try to add a BuildConflicts yesterday to either the
glut or freeglut packaging. The proposed packaging I posted yesterday
didn't cause glut to be removed automatically when freeglut was built
and freeglut to be removed when glut was built. Since the freeglut
examples seem to
that need glut.
Jack
Package: freeglut
Version: 2.2.0
Revision: 2
GCC: 3.3
Maintainer: Jack Howarth [EMAIL PROTECTED]
Source: mirror:sourceforge:freeglut/%N-%v.tar.gz
Source-MD5: 9439b8745f443131c2dad00bc93dc0ef
Dan,
I believe I finally have the revised glut and freeglut packaging done.
I have submitted their info files onto the tracking server as well as
revised info files for molmol and pymol so they can be built against either.
Let me know if there are any problems but everything is passing
Is there anything I can do to accelerate the movement of the
revised packaging I have submitted for glut, freeglut, pymol and molmol
through the tracking system and into unstable fink 10.3? These submissions
are...
Daniel,
Can you give me some guidance on what approach I should take with
the freeglut/glut dependency? I assume you are using the freeglut/glut
packages from 10.3 unstable that I recently submitted which should have
resolved the conflicts between the two. However the absence of true
Dan,
What else do I need to do to get the new variant version of
the pymol package (now pymol-py) into fink unstable?
Jack
ps The pymol-py.info and pymol-py.patch files are both uploaded into
the fink package tracker. Note that these would both replace the
current pymol.info
Dan,
I have uploaded a new revision of the pymol-py.info file which limits
the package to building against freeglut. This should eliminate your last
remaining complaint. Can we please proceed with depreciating the pymol
package from fink 10.3 and 10.4-transitional unstable and replacing it
Dan,
I have noticed that the recent changes to fink in 10.4-transitional
unstable make builds very fragile. For example, if one has glut and
glut-shlibs installed and with the new proposed packaging for pymol-py
(which limits the build to against freeglut) installed in
Martin,
I don't think it is wise to remove the BuildConflicts for freeglut
and glut. The current freeglut and glut packaging has freeglut built
as libfreeglut rather than libglut to avoid the binary incompatibility
of the libraries. However to avoid requiring any package that wants
to use
I have submitted revised version of the glut (3.7-25) and the
freeglut (2.2.0-3) packages for fink unstable into the tracking
system. The only changes made were the removal of the Build-Conflicts
line which currently isn't handled properly under fink. This change
will prevent fink from
I have resubmitted the pymol-py package as new package on the
tracker since I was having no luck whatsoever in getting this into
unstable. Once again, this pymol-py package replaces the current
pymol package and allows builds against python2.2, python2.3 or
python2.4 with the resulting
Koen,
The pymol-py package should go in both the 10.3 and
10.4-transitional trees (unstable). Thanks in advance.
Jack
---
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Koen,
Thanks for getting the modified freeglut and glut packages in
10.3 and 10.4-transitional unstable. I have one last request. I
have uploaded a new molmol.info file (2k.2.0-19) for the unstable
branch of 10.4-transitional. This version builds against gcc-4.0
and freeglut. It passes fink
Koen,
As requested by Daniel, I have reverted the molmol 2k.2.0-19
package to build with gcc-3.3 once again rather than gcc-4.0.
This version will be okay for both 10.3 and 10.4-transitional
unstable. It is uploaded into the tracker...
Koen,
Well in the case of glut and freeglut, I have verified that the
builds aren't leaky. The glut build never looks in /sw/lib or
/sw/include for headers or libraries. The freeglut build is safe
with glut installed since it uses the freeglut basename for its
headers and libraries and thus
Peter,
I had read the posts before about the ABI changes for c++
and knew that g++-3.3 was going to be retained as the default
compiler for fink 10.4. However, I hadn't seen any explicit
mention of gcc-4.0 being the c compiler.
Jack
Peter,
I checked on the gcc mailing list and Mike Stump at Apple Computer
replied...
http://gcc.gnu.org/ml/gcc/2005-05/msg01515.html
As I suspected, there will be cases of breakage when g++-3.3 is
used to link programs containing gcc-4.0 generated object code.
So we will have to be on the
Jeffrey,
Could you possibly add a gfortran package to fink unstable based off
of the main trunk or 4.1 branch? Since g95 and gfortran have heavily
forked, any bugs I find and report against g95 aren't easily checked
against the current gfortran code to see it the problem exists there.
It
Peter,
For the features I need from gfortran, I'll need to be on the
4.1 branch. We should be testing that anyway since it is slated for
release in Sept. In any case, I am trying the following gfortran.info
at the moment...
Peter,
I think one can hardly call the g95 compilers we currently put out
as 'released compilers'. These are daily snapshot builds of g95 which
are broken and fixed at regular intervals.
As for the gcc-4.0.1 package...what is its real purpose? The
compilers other than c and c++ are likely
Peter,
You may have point regarding the 4.1 branch, but I would say that
the 4.0.2 branch is highly unlikely to be much less stable for gfortran
than the 4.0.1 release is. Again the question really is what is the
purpose of the gcc4 package? If it is primarily a release mechanism
for gfortran,
Still one has to ask exactly which compilers in the gcc4 package
we should be focusing on? The gfortran compiler specifically is making
really good progress. With patches to be added today, it should pass
almost all of the NIST Fortran validation testsuite. I think we would be
far better off
Now that the gcc developers have switched over to svn and
stopped keeping their cvs tree as current, I decided to fink
install the svn-client under MacOS X 10.4.3. However I found
that 'svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc' appears
to take more than a order of magnitude longer
Since a new gromacs, version 3.3 has been released, I will be
updating the fink gromacs package soon. However, we will need to
address the breakage in g77 from Xcode 2.2 for the required
lammpi support to work. The last time I asked any of the Darwin
programmers about the buried path to
Jeffrey,
FYI, I have finished a revised fftw3.info script which allows
-mpi versions of fftw3 to be built as we currently do for fftw. I
will need the mpi support in fftw3 when I upgrade the gromacs-mpi
package to version 3.3 which was just released. Currently I am
stuck on some new shared
Has anyone tried updating lammpi from fink 10.4-transitional unstable
to the newer 7.1.1 release source code? I am seeing the same thing that
William Scott was. The fink packaging produces a lammpi for 7.1.1 which
appears to compile and install fine but is unable to execute lamboot
properly. I
I don't understand why this build problem happens under fink but I
believe I have identified the offending file. It appears that the breakage
in the fink build of lam 7.1.1 originates in the liblam.0.0.0.dylib
shared library. Oddly the fink built version shows...
otool -L liblam.0.0.0.dylib
Oddly I see to see that when fink links liblam.0.0.0.dylib with gcc called
as gcc-4.0, I have...
gcc-4.0 -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o
.libs/liblam.0.0.0.dylib ...etc
whereas when I build lam 7.1.1 manually I end up with...
gcc -dynamiclib ${wl}-flat_namespace
Peter,
Actually 'NoSetMACOSX_DEPLOYMENT_TARGET: true' is insufficient.
I had to resort to 'SetMACOSX_DEPLOYMENT_TARGET: 10.2' in order to
force libtool to use -undefined suppress. I'll post the packaging I
have into the fink tracking system later today. There also was a patch
I added to force
I have posted new gromacs and gromacs-mpi 3.3-1 packages on
the fink tracking system. While upgrading gromacs, I noticed that
the lammpi build for 7.1.1 needed fixing for fink packaging and
have posted 7.1.1-1 packaging which produces a working lamboot.
Lastly I have updated the fftw3 packages
I have posted three updated packages on the fink tracking system
for lammpi 7.1.1-1, fftw3-3.0.1-1 and gromacs/gromacs-mpi 3.3-1.
However I discovered afterwards that while the lam-7.1.1-1 package
has a working lamboot it seems to have broken the linking of gromacs-mpi.
I am now seeing errors
Peter,
I have verified that the current gromacs-mpi packaging for 3.3-1 in
fink tracking builds fine against the lam-7.0.6-11 currently in unstable.
The problem seems to be specific to lam-7.1.1. With the lam-7.1.1-1
package installed (which was built with MACOSX_DEPLOYMENT_TARGET 10.2),
I
Peter,
Actually I think the problem with lam 7.1.1 originates more from the
massive changes they have made to its aclocal.m4 file. The libtool that
is generated from configure during the build shows the following diffs
from that generated by lam 7.0.6...
# How to create reloadable object
Peter,
Are you certain it is the need for -fPIC is limited at all with
regard to static code in shared libs. In his article, Drepper says...
The most important recommendation is to always use -fpic or -fPIC
when generating code which ends up in DSOs. This applies to data as
well as code. Code
Peter,
Hmmm. Is -fPIC and -fno-common equivalent? I specifically recall that
I had to add -fno-common to the compilation of the static lib liblammpio.a
to eliminate the common symbols in it and thus eliminate the need for
the -W1,-single-module hack to build gromacs-mpi's shared libs. I would
Peter,
FYI, James Gibbs just emailed me to say he should no longer be considered
an active developer and not to wait on him to submit the new packaging for
lammpi 7.1.1-1. He said that I could adopt maintaining lammpi or it could
be considered unowned. I'll be happy to maintain lammpi and
Is anyone having problems with the pymol-py package. I got a report
today about undefined symbols for _XF86VidModeGetViewPort referenced
from libfreeglut.3.dylib in _cmd.so. I don't see this under Xcode 2.2
but on our G4s I am finding that pymol has a bus error when it gets to
the point of
If a package uses a patchscript rather than the automatic
patch application by fink, is there a recommended approach to
aborting the build if the patch is missing. I just noticed
that 'fink install pymol-py24' will build against the python 2.3
headers if the pymol-py.patch file is missing. Are
I've puzzled out the general cause of the bus errors on the G4 here
at work with pymol. Since I had two equal sized drives in the machine
and the system drive was getting full, I had archived the /sw directory
and moved it over to /Volumes/Data with a symlink in the root partition
of the
While testing the apbs and pdb2pqr packages (which run their python
scripts using /usr/bin/python), I discovered some potential breakage. The
current info scripts for these packages have a Depends on python. However
since these packages (at least pdb2pqr for sure) build extensions against
the
Daniel,
I figured out last night that passing configure 'py_path=/usr/bin/python'
seems allow the system python to be properly located even if the fink
python package is installed. I'll take a look at some of the other fink
packages still using python as a depends to try to identify which ones
Martin,
Here I get...
ftp ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/unix-gzip
Connected to imb-sv-30.ethz.ch.
220 Welcome to Molecular Biology FTP service.
331 Please specify the password.
230-
230- Welcome to the ftp-Server of the Biophysics Group
230-
Daniel,
Can we move freeglut into stable so that we can have pymol-py
in stable as well? I don't believe there is anything left broken
in freeglut now. It builds its libs as libfreeglut and none of the
existing packages should still have glut|freeglut (i.e. they all
pick one or the other for
Michal,
No, freeglut and glut are not interchangable. However, freeglut now
builds with -disable-replace-glut so that it remains named as libfreeglut
rather than libglut. I do have the freeglut package symlink...
ln -s libfreeglut.3.dylib %i/lib/libglut.dylib
as well as the headers, so that
Dave,
For the sparky-py fink packages, I have a sparky-py.patch which
patches the Makefile to have ...
-CXX= g++
-CXXFLAGS =
+CXX= g++-3.3
+CXXFLAGS = -O3 -ffast-math -mtune=970 -fPIC -fno-common -Wno-long-double
CC = gcc
-CFLAGS =
I am wondering if anyone with a MacIntel box can tell me
what the default settings for the Apple gcc 4.0 compiler are on
that architecture for -mtune and -march? Several web sites
recommend the use of -mtune=prescott -march=pentium-m for FSF gcc.
Are these the automatic defaults in Apple's
Martin,
That doesn't quite make sense. How can MacIntel use nocona if
the Core Duo's don't have the EMT64 extensions?
Jack
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends
Has work on the 10.4 branch stalled? I have noticed for the past
several weeks that 'fink selfupdate' from the cvs doesn't seem to pull
down any new updates. Only the messages about...
cvs update: -m wrapper option is not supported remotely; ignored
I starting to wonder if the cvs part of
I discovered that the gmp developers have been incorrectly building
non-PIC code into their shared libraries. They have been using -fast
which sets -mdynamic-no-pic without adding an explicit -fPIC. I recall
some discussion on the debian mailing lists of checking for non-PIC code
in linux
Jeff,
Now that gmp 4.2 is in unstable we will need to patch gcc4
to build against it. This issue is discussed in the thread...
http://gcc.gnu.org/ml/fortran/2006-04/msg00183.html
and the proposed patch is in...
http://gcc.gnu.org/ml/fortran/2006-04/msg00190.html
which changes the dependency
I am wondering why packages like fftw3 are depending on g95
rather than gfortran? While this may be useful in the short term
I think we would be far better off with gfortran in the long run.
As far as I know the g95 source still is devoid of a decent test
suite so there is no good way to
Martin,
Have you tried the current gcc 4.1 branch from snapshot or svn?
I would avoid gcc 4.2 for now since it is so far from release. However
there are a huge number of fixes in the 4.1 branch for gfortran since
the 4.1.0 release. They might have backported the MacIntel changes
into that
Jeff,
The gcc developers are still hashing over how to introduce the
required patches for gmp 4.2.x since it no longer builds gmp against
mpfr and must gfortran must link mpfr in explicitly. The patch I sent
you a few weeks ago is still valid and can should be used for the gcc
4.1.1 package in
The cctoools installed by Xcode 2.3 apparently resolves the
ld64 bugs in that were forcing gcc4 to be built with --disable-multilib...
http://gcc.gnu.org/ml/gcc/2006-06/msg00160.html
I'l try to get Geoffrey Keating to release a new cctool release
in infrastructure of the gcc.gnu.org ftp
Jeff,
According to Geoffrey Keating at Apple, the cctools from Xcode 2.3
eliminates the problem with ld64 which was forcing us to build gcc4
for 4.2 with --disable-multlib. While there isn't a new odcctools tarball
yet, you can roll your own for a odcctools based on the same cctools
590.42.1
Having noticed an odd c++ regression in gcc 4.2 built with the
gcc4.info file from 10.4 unstable fink, I have been building gcc
trunk for the last couple of weeks on a G5. I noticed if I build
without the gcc4.patch applied that I end up with a slew of new
g++ testsuite regressions. However,
Peter,
The problem is that almost no one is testing gcc trunk on darwin
except for Apple. However they don't build things like gfortran so
that breakage there can go unreported for quite a while. Most
worrisome is the testsuite results like...
In case anyone else is following gcc trunk with fink installed,
I should clarify what I have found so far. If I have fink installed
(but not odcctools), I can build gcc trunk from the gcc svn against
Xcode 2.3. However, if fink is sourced I get the odd g++ regressions.
If fink isn't sourced,
Matthew,
I'll try a build tonight of gcc trunk with fink sourced but with
the path reset to eliminate any directories in /sw. That should
tell me if the problem is some binary in /sw/bin or /sw/sbin
effecting the gcc trunk build.
Jack
Matthew,
I see the same g++ regressions (when I build gcc trunk under fink
with odcctools deinstalled and Xcode 2.3 installed) as reported here...
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00221.html
I am waiting to hear back from Bradley about the details of his build
configuration.
Matthew,
I believe I have pinpointed the component in fink 10.4 that was
causing the c++ regressions in gcc trunk when built with fink sourced.
After deinstalling bison 2.1 installed by fink, I find that gcc builds
without c++ regressions. The regressions that previously occurred were
those
I have confirmed that the c++ regressions I have been seeing in
gcc trunk are specific to having the fink bison 2.1 package installed
during the gcc build. If build with either the bison 2.1 package
deinstalled or with a bison 2.3 package installed, the c++ regressions
don't occur. I strongly
Martin,
Why would you think that a 2.x release series of bison wouldn't
be backwardly compatible?
Jack
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
JF,
I checked it with some echo statements in the compile
script. The only set in fink for the gcc4 build is
SetMACOSX_DEPLOYMENT_TARGET. I've added...
NoSetMACOSX_DEPLOYMENT_TARGET: True
to gcc4.info and will try a build of tonight's gcc trunk.
Hopefully this is the source of the g++
Jeff,
I figured out the g++ regressions I have been suffering with gcc
trunk built as a fink package. The problem is in PR 26792...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
and can be solved simply by adding...
NoSetMACOSX_DEPLOYMENT_TARGET: True
...to gcc4.info. You will also want
Martin,
Well, from the comments in the PR, Geoff was protecting the
10.4 version of libgcc. I believe they are free to add that
symbol to 10.5's libgcc however. FYI, what I have been doing is
using gcc4 built with the current gcc trunk to build xplor-nih.
In doing so I noticed a c++ regression
Martin,
Actually I thought of adding bison to the BuildConflicts for gcc4.
However I still think upgrading to bison 2.3 can't be that bad of a
move since it is a .X release. Anyway I try to be an optimist about
the eventual progress in software development (however convoluted
the path may be).
Peter,
I'll test it. Hopefully we can get the odcctools update into
fink soon and Jeff can create a new gcc4 from the next snapshot
with '--disable-multlib' dropped and MACOSX_DEPLOYMENT_TARGET
unset for that package. I would also not that Mike Stump has
made a recent change that we really
1 - 100 of 1201 matches
Mail list logo
