Hi Mike, 

I can build without modifying configure.in; I'm not sure why I bother to modify 
it. At one point I guess I just wanted to see what I really needed. 


Thanks for explaining the reason for that -dylib_file option. That really 
seemed pointless to me. 


Louis 


----- Original Message ----- 
From: "Michael Petch" <[email protected]> 
To: "Louis P Zulli" <[email protected]>, "Christian Anthon" 
<[email protected]> 
Cc: [email protected] 
Sent: Monday, March 30, 2009 8:59:49 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [Bug-gnubg] Darwin-specific LDFLAGS in configure.in 

Regarding LDFLAGS- I was the one who put this in (Or informed Christian to do 
it) - Its been a while. 

The duplicated syntax was needed with earlier version of OS/X (Tiger 
specifically). It may not be needed anymore with newer versions of Xcode and 
Leopard. Without the syntax previous builds would not link properly. So I’d say 
keep it in to allow for easier builds on older platforms. The duplication may 
look odd, but it was a necessity (I thought it peculiar when I first saw it). 
This was documented on apple.com in a knowledgebase some time ago. 

As for `/opt/local/bin/pkg-config --libs glib-2.0`. This is Macports specific. 
People who use “Roll your own method” - it doesn’t apply to and should return 
blank (the /opt directory doesn’t exist so pkg-config can’t run). Do you remove 
it because it causes you problems? 

I’d say unless it causes an issue they should be kept the way they are to allow 
for a broader build base to succeed. I’ve been doing builds on OS/X (PPC and 
Intel for years) and there have been a number of anomalies on each upgrade that 
are fixed by some hack like this. 


On 30/03/09 6:31 PM, "Zulli, Louis P" < [email protected] > wrote: 



Hi Christian, 

Regarding the following portion of configure.in: 



*-*-darwin*) 
LDFLAGS="$LDFLAGS -dylib_file 
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
 -framework QuickTime `/opt/local/bin/pkg-config --libs glib-2.0`" 
;; 

First, why use the -dylib_file option, given that its two path arguments are 
identical? Seems pointless to me. See the following portion of the ld man page: 

-dylib_file install_name:file_name 
Specifies that a dynamic shared library is in a different 
location than its standard location. Use this option when you 
link with a library that is dependent on a dynamic library, 
and the dynamic library is in a location other than its 
default location. install_name specifies the path where the 
library normally resides. file_name specifies the path of the 
library you want to use instead. For example, if you link to 
a library that depends upon the dynamic library libsys and 
you have libsys installed in a nondefault location, you would 
use this option: -dylib_file /lib/lib- 
sys_s.A.dylib:/me/lib/libsys_s.A.dylib. 


Second, is the explicit pkg-config call necessary? I routinely remove it (and 
the -dylib_file option too) and no problems arise. Is this actually needed for 
folks for use MacPorts? (I don't have /opt/local ) 

I suppose "better safe than sorry" is a good philosophy to have, but while you 
are cleaning things up I thought I'd call this matter to your attention. 
Perhaps other Mac users who build from source can offer their insights. 

Thanks, 
Louis 



_______________________________________________ 
Bug-gnubg mailing list 
[email protected] 
http://lists.gnu.org/mailman/listinfo/bug-gnubg 

_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg

Reply via email to