libtool vs collect2 on Mac linker inconsistency

Hi, I'm working on a test program for a larger project but
am having 
trouble getting it to link.  The larger project is a dynamic
library 
that is linking against GraphicsMagick-1.1.8.  I have been
using the 
same arguments and paths as below to build a *.dylib file
with no 
problem.  Looking at the verbose output, the only difference
in the 
builds is the program being used to link.  In this failing
version, the 
linker command seems to be 
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/collect2 but in
the successful 
library build it is using /usr/bin/libtool.

Interestingly, if I remove the
"-lGraphicsMagick++" argument in the 
Makefile, the errors change to complain about missing
Magick::Image 
constructors and other C++ constructs.  If I remove the 
"-lGraphicsMagick" argument the errors remain as
below.

Here are the commands in my Makefile:

g++ -w -c -o gm_test.o -I/usr/local/include/GraphicsMagick
gm_test.cpp
g++ -v -o gm_test gm_test.o -L/usr/local/lib
-lGraphicsMagick 
-lGraphicsMagick++

Here is the source (basically a dummy program now):

#include "Magick++.h"
#include <iostream>
#include <sstream>
#include <string>
//#include <sys/stat.h>

using namespace std;
using namespace Magick;

#define PATH
"/Users/rcrowley/Desktop/crap/IMG_1725-rotate.JPG"


int main(int, char * *) {
	Image img(PATH);
	return 0;
}

And here is a sample of the build output:

g++ -w -c -o gm_test.o -I/usr/local/include/GraphicsMagick
gm_test.cpp
g++ -v -o gm_test gm_test.o -L/usr/local/lib
-lGraphicsMagick 
-lGraphicsMagick++
Using built-in specs.
Target: i686-apple-darwin8
Configured with:
/private/var/tmp/gcc/gcc-5367.obj~1/src/configure 
--disable-checking -enable-werror --prefix=/usr
--mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ 
--with-gxx-include-dir=/include/c++/4.0.0
--with-slibdir=/usr/lib 
--build=powerpc-apple-darwin8 --with-arch=nocona
--with-tune=generic 
--program-prefix= --host=i686-apple-darwin8
--target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5367)
  /usr/libexec/gcc/i686-apple-darwin8/4.0.1/collect2
-dynamic -arch i386 
-macosx_version_min 10.3 -multiply_defined suppress 
-weak_reference_mismatches non-weak -o gm_test -lcrt1.o 
/usr/lib/gcc/i686-apple-darwin8/4.0.1/crt3.o
-L/usr/local/lib 
-L/usr/lib/gcc/i686-apple-darwin8/4.0.1 
-L/usr/lib/gcc/i686-apple-darwin8/4.0.1 
-L/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../.. gm_test.o 
-lGraphicsMagick -lGraphicsMagick++ -lstdc++ -lgcc_s.10.4
-lgcc -lSystem
/usr/bin/ld: Undefined symbols:
_DestroyExceptionInfo
_GetExceptionInfo
### More similarly named undefined symbols
_GetGeometry
_GetPageGeometry
collect2: ld returned 1 exit status
make: *** [test] Error 1

Thanks for any help anyone can provide,

Richard

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

On Wed, 22 Aug 2007, Richard Crowley wrote:

> Hi, I'm working on a test program for a larger project
but am having
> trouble getting it to link.  The larger project is a
dynamic library
> that is linking against GraphicsMagick-1.1.8.  I have
been using the
> same arguments and paths as below to build a *.dylib
file with no
> problem.  Looking at the verbose output, the only
difference in the
> builds is the program being used to link.  In this
failing version, the
> linker command seems to be
> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/collect2 but
in the successful
> library build it is using /usr/bin/libtool.
>
> Interestingly, if I remove the
"-lGraphicsMagick++" argument in the
> Makefile, the errors change to complain about missing
Magick::Image
> constructors and other C++ constructs.  If I remove
the
> "-lGraphicsMagick" argument the errors remain
as below.
>
> Here are the commands in my Makefile:
>
> g++ -w -c -o gm_test.o
-I/usr/local/include/GraphicsMagick gm_test.cpp
> g++ -v -o gm_test gm_test.o -L/usr/local/lib
-lGraphicsMagick
> -lGraphicsMagick++

Since -lGraphicsMagick++ depends on symbols in
-lGraphicsMagick, try 
reversing the order to '-lGraphicsMagick++
-lGraphicsMagick'.  While 
it would be nice if linkers always handled reverse
references, many do 
not.  Additional libraries are likely required.  Libtool
uses 
installed .la files to build a list of the additional
libraries which 
are required.

The installed GraphicsMagick++-config script can be used to
obtain a 
working build incantation:

% GraphicsMagick++-config --help
Usage: GraphicsMagick++-config [--cppflags] [--cxxflags] 
[--exec-prefix] [--ldflags] [--libs] [--prefix] [--version]

  For example, "example.cpp" may be compiled to
produce "example" as
  follows:

   "c++ -o example example.cpp `GraphicsMagick++-config
--cppflags
   --cxxflags --ldflags --libs`"

% GraphicsMagick++-config --ldflags
-L/usr/local/lib -L/usr/local/lib -L/usr/X11R6/lib
-L/usr/X11R6/lib 
-L/usr/local/lib

% GraphicsMagick++-config --libs
-lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff -lfreetype
-ljasper 
-ljpeg -lpng -ldpstk -ldps -lXext -lSM -lICE -lX11 -lxml2
-lz -lm 
-lpthread

% GraphicsMagick++-config --cppflags
-I/usr/local/include/GraphicsMagick

The above sample command executions are from a Mac.  The 
natives on this island are friendly. 

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

That's a winner, thanks.
Rich

Bob Friesenhahn wrote:
> On Wed, 22 Aug 2007, Richard Crowley wrote:
> 
>> Hi, I'm working on a test program for a larger
project but am having
>> trouble getting it to link.  The larger project is
a dynamic library
>> that is linking against GraphicsMagick-1.1.8.  I
have been using the
>> same arguments and paths as below to build a
*.dylib file with no
>> problem.  Looking at the verbose output, the only
difference in the
>> builds is the program being used to link.  In this
failing version, the
>> linker command seems to be
>> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/collect2
but in the successful
>> library build it is using /usr/bin/libtool.
>>
>> Interestingly, if I remove the
"-lGraphicsMagick++" argument in the
>> Makefile, the errors change to complain about
missing Magick::Image
>> constructors and other C++ constructs.  If I remove
the
>> "-lGraphicsMagick" argument the errors
remain as below.
>>
>> Here are the commands in my Makefile:
>>
>> g++ -w -c -o gm_test.o
-I/usr/local/include/GraphicsMagick gm_test.cpp
>> g++ -v -o gm_test gm_test.o -L/usr/local/lib
-lGraphicsMagick
>> -lGraphicsMagick++
> 
> Since -lGraphicsMagick++ depends on symbols in
-lGraphicsMagick, try 
> reversing the order to '-lGraphicsMagick++
-lGraphicsMagick'.  While it 
> would be nice if linkers always handled reverse
references, many do 
> not.  Additional libraries are likely required. 
Libtool uses installed 
> .la files to build a list of the additional libraries
which are required.
> 
> The installed GraphicsMagick++-config script can be
used to obtain a 
> working build incantation:
> 
> % GraphicsMagick++-config --help
> Usage: GraphicsMagick++-config [--cppflags]
[--cxxflags] [--exec-prefix] 
> [--ldflags] [--libs] [--prefix] [--version]
> 
>  For example, "example.cpp" may be compiled
to produce "example" as
>  follows:
> 
>   "c++ -o example example.cpp
`GraphicsMagick++-config --cppflags
>   --cxxflags --ldflags --libs`"
> 
> % GraphicsMagick++-config --ldflags
> -L/usr/local/lib -L/usr/local/lib -L/usr/X11R6/lib
-L/usr/X11R6/lib 
> -L/usr/local/lib
> 
> % GraphicsMagick++-config --libs
> -lGraphicsMagick++ -lGraphicsMagick -llcms -ltiff
-lfreetype -ljasper 
> -ljpeg -lpng -ldpstk -ldps -lXext -lSM -lICE -lX11
-lxml2 -lz -lm -lpthread
> 
> % GraphicsMagick++-config --cppflags
> -I/usr/local/include/GraphicsMagick
> 
> The above sample command executions are from a Mac. 
The natives on this 
> island are friendly. 
> 
> Bob
> ======================================
> Bob Friesenhahn
> bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/
> 


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help