htdig-dev

[htdig-dev] Undefined symbols in OS X

[Jim C. <li...@yg...>]

Hi - I have a bit more information regarding the C++ related undefined 
symbols. The symbol names that show up as undefined match exactly those 
in OS X's libstdc++. So it looks like it is an issue of things not 
being found, rather than anything that is truly missing.

Additionally, I discovered that setting the DYLD_INSERT_LIBRARIES 
environment variable to the full path to libstdc++.dylib before running 
an ht://Dig program seems to solve the problem of undefined symbols. 
This variable is used to specify dynamic libraries that should be 
loaded before any specified directly by a program. I think it is 
primarily intended for testing, but it does seem to identify the nature 
of the problem. Apparently the current build system somehow fails to 
record a libstdc++.dylib dependency, resulting the library not being 
loaded at runtime.

All of the above holds regardless of the version of libtool used. Or at 
least for the current version and 1.5.

Jim

[htdig-dev] Re: Undefined symbols in OS X

[Lachlan A. <lh...@us...>]

Good work, Jim!

Unfortunately,  locate libstdc++  on the SourceForge compile farm only=20
finds  .a  files:

    lha@ucf-cf-ppc-macosx-2:~/htdig$ locate libstdc++
    /usr/lib/gcc/darwin/2.95.2/libstdc++.a
    /usr/lib/gcc/darwin/3.1/libstdc++.a
    /usr/lib/libstdc++.a
    lha@ucf-cf-ppc-macosx-2:~/htdig$

That would certainly explain why it doesn't find the symbols!  Where=20
is the file on your system, Jim?  Does anyone know why it isn't on=20
the compile farm??

Cheers,
Lachlan

On Mon, 5 May 2003 12:43, Jim Cole wrote:
> I have more information regarding the C++ related
> undefined symbols. The symbol names match
> those in libstdc++. So it looks like it is an issue
> of things not being found, rather than anything that is truly
> missing.
>
> Additionally, I discovered that setting DYLD_INSERT_LIBRARIES
> to the full path to libstdc++.dylib seems to solve the problem.

Re: [htdig-dev] Re: Undefined symbols in OS X

[Jim C. <li...@yg...>]

On Monday, May 12, 2003, at 12:40 PM, Lachlan Andrew wrote:

> Unfortunately,  locate libstdc++  on the SourceForge compile farm only
> finds  .a  files:
>
>     lha@ucf-cf-ppc-macosx-2:~/htdig$ locate libstdc++
>     /usr/lib/gcc/darwin/2.95.2/libstdc++.a
>     /usr/lib/gcc/darwin/3.1/libstdc++.a
>     /usr/lib/libstdc++.a
>     lha@ucf-cf-ppc-macosx-2:~/htdig$
>
> That would certainly explain why it doesn't find the symbols!  Where
> is the file on your system, Jim?  Does anyone know why it isn't on
> the compile farm??

On my system it is located in /usr/lib/gcc/darwin/3.1/private/A. Also, 
there is a dynamic link in /usr/lib/gcc/darwin/3.1/private/.

   /usr/lib/gcc/darwin/2.95.2/libstdc++.a
   /usr/lib/gcc/darwin/3.1/libstdc++.a
   /usr/lib/gcc/darwin/3.1/private/A/libstdc++.dylib
   /usr/lib/gcc/darwin/3.1/private/libstdc++.dylib
   /usr/lib/libstdc++.a

This may be a relatively recent addition as I don't recall the .dylib 
files being present at this location the last time I dug into the 
problem of unresolved symbols. But it has been a while, so I might be 
mistaken. Then again, if they are not present on the compile farm... 
Perhaps there is a difference in OS X version or installed Developer 
Tool updates. I am using 10.2 (Jaguar) and the Developer Tools that 
came with that release, including the October and December updates.

[magni:~] greyleaf% uname -a
Darwin magni.yggdrasill.net 6.6 Darwin Kernel Version 6.6: Thu May  1 
21:48:54 PDT 2003; root:xnu/xnu-344.34.obj~1/RELEASE_PPC  Power 
Macintosh powerpc

[magni:~] greyleaf% gcc --version
gcc (GCC) 3.1 20020420 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


Jim