On 7/10/06, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Benjamin,
> Yes, freeglut has a BuildDepends on x11-dev. The user didn't get
> the package to build (because he didn't realize X11SDK wasn't installed)
> and had somehow hacked the build to work by changeing the includes
> from GL/gl.h to Op
Benjamin,
Yes, freeglut has a BuildDepends on x11-dev. The user didn't get
the package to build (because he didn't realize X11SDK wasn't installed)
and had somehow hacked the build to work by changeing the includes
from GL/gl.h to OpenGL/gl.h. The point is that it would seem that fink
isn't bei
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jack Howarth wrote:
>I had a report today from a fink user who had problem building
> the freeglut package. The problem was that he had forgotten to install
> the X11SDK. Does anyone know what if any warning fink gives when a
> package requiring x1
On 7/10/06, Jack Howarth <[EMAIL PROTECTED]> wrote:
>I had a report today from a fink user who had problem building
> the freeglut package. The problem was that he had forgotten to install
> the X11SDK. Does anyone know what if any warning fink gives when a
> package requiring x11-dev is built
I had a report today from a fink user who had problem building
the freeglut package. The problem was that he had forgotten to install
the X11SDK. Does anyone know what if any warning fink gives when a
package requiring x11-dev is built without the system-xfree86-dev
virtual package being install
One other observation on this situation. I have noticed that RedHat
(who is never shy to use pre-release gcc's or glibc's in Fedora) still
hasn't adopted gcc 4.2 in either their development or FC6 testing
releases. This is a big red flag that gcc trunk is too volatile for
use in released softwar
Dave,
In this case, I don't think the approach of making a compatibility
package is appropriate or wise. The current gcc4 in unstable, based
on the gcc snapshots, is neither fish nor fowl. It has a libgfortran
which has alway forked away from the ABI used in libgfortran from gcc
4.1.x. So to cl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David R. Morrison wrote:
> The standard way of handing this situation is to introduce a new
> package name for the package which provides a shared library that is
> not backward compatible with the previous one. So, for example,
> gdbm3-shlibs i
The standard way of handing this situation is to introduce a new
package name for the package which provides a shared library that is
not backward compatible with the previous one. So, for example,
gdbm3-shlibs instead of gdbm-shlibs. That is why the symlink from /
sw/lib/libgdbm.dylib is
We are going to have problems soon with anything built with
the gfortran from the gcc4 package in unstable. The libgfortran in
the gcc trunk has forked enough from the ABI of the previous 4.1.x
versions that the gcc developers will be bumping the versioning on
that shared library. It hasn't hap
10 matches
Mail list logo
