Martin,
I have found a small example program called opensolar.c which demonstrates
the linkage problem under Leopard. The following build commands both work under
Tiger...
gcc -I/usr/include -I/usr/X11R6/include -I/sw/include opensolar.c -L/sw/lib
-L/usr/X11R6/lib -lXm -lGLU -lGL
/System/Lib
On Oct 28, 2007, at 2:16 PM, Jack Howarth wrote:
> Martin,
>Some of the linker behavior in Leopard doesn't make any sense at
> all. For example if I
> modify the molmol makedef to link as follows (which works fine under
> Fedora 7 linux)...
I think this is a general problem in the new ld
Martin,
Some of the linker behavior in Leopard doesn't make any sense at all. For
example if I
modify the molmol makedef to link as follows (which works fine under Fedora 7
linux)...
cd main; make default
/usr/bin/gcc -o molmol -I../../tools/include -I../../sg/include -I../../include
-DMAXI
Jack Howarth wrote:
> Martin,
> I have just been able to get molmol to link using a libGLw.a
> built from a copy of the original widgets-sgi sources (that I use
> for linux builds of molmol rpms) and the hack you mention below.
> While this completes the linkage, the resulting binary doesn't
>
Martin,
I have just been able to get molmol to link using a libGLw.a
built from a copy of the original widgets-sgi sources (that I use
for linux builds of molmol rpms) and the hack you mention below.
While this completes the linkage, the resulting binary doesn't
render properly. It produces no
Martin,
This isn't quite the case here. I have been told by Apple's
programmers that these linker checks on cyclic use of libraries
has been in place for almost a year now in Xcode 3.0. This means
that had the X11 component been ported to the new linker in
a timely manner, there would have been p
Jack Howarth wrote:
> This is a corner case of the same problem with no possible workaround.
> The problem is that libGL is a unique library in that it needs to exist
> in a special X11 version with additional symbols. The libGLw library
> uses some of these symbols unique to the X11 version of lib
This is a corner case of the same problem with no possible workaround.
The problem is that libGL is a unique library in that it needs to exist
in a special X11 version with additional symbols. The libGLw library
uses some of these symbols unique to the X11 version of libGL.dylib and
thus the nasty
Have you seen
http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug
?
I'm not sure it is the same issue with libGL.dylib that I had with
aqbanking16, but the SetLDFLAGS addition worked for me.
Dave
On 27 Oct 2007, at 10:50:14 PM, Jack Howarth wrote:
> The mo
The molmol package will be unportable to Leopard
until the current breakage in Xcode is fixed. The problem
is that libGLw needs symbols such as _glXChooseVisual which
only exist in the /usr/X11R6/lib copy of libGL.dylib and thus
is unlinkable under Xcode 3.0.
Jack
10 matches
Mail list logo
