42 messages in org.apache.incubator.stdcxx-devRe: ABI problem on Darwin
FromSent OnAttachments
Martin SeborApr 24, 2008 9:44 pm 
Martin SeborApr 25, 2008 11:47 am 
Martin SeborApr 27, 2008 10:17 pm.run, .run
Eric LemingsApr 28, 2008 7:58 am 
Martin SeborApr 28, 2008 9:00 am 
Eric LemingsApr 28, 2008 9:11 am 
Martin SeborApr 28, 2008 9:24 am 
Travis VitekApr 28, 2008 10:18 am 
Liviu NicoaraApr 28, 2008 11:45 am.out, .out
Martin SeborApr 28, 2008 9:44 pm 
Martin SeborApr 28, 2008 9:55 pm 
Eric LemingsApr 29, 2008 7:43 am 
Eric LemingsApr 29, 2008 8:10 am 
Eric LemingsApr 29, 2008 9:23 am 
Eric LemingsApr 29, 2008 9:45 am 
Travis VitekApr 29, 2008 11:09 am 
Eric LemingsApr 29, 2008 11:35 am 
Farid ZaripovApr 29, 2008 11:51 am 
Eric LemingsApr 29, 2008 12:28 pm 
Travis VitekApr 29, 2008 1:25 pm 
Travis VitekApr 29, 2008 1:55 pm 
Travis VitekApr 29, 2008 2:15 pm 
Eric LemingsApr 29, 2008 2:21 pm 
Travis VitekApr 29, 2008 4:19 pm 
Eric LemingsApr 29, 2008 4:47 pm 
Martin SeborApr 29, 2008 5:21 pm 
Martin SeborApr 29, 2008 5:42 pm 
Martin SeborApr 29, 2008 5:51 pm 
Eric LemingsApr 30, 2008 7:52 am 
Martin SeborApr 30, 2008 8:21 am 
Martin SeborApr 30, 2008 8:37 am 
Eric LemingsApr 30, 2008 9:12 am 
Martin SeborApr 30, 2008 9:42 am 
Martin SeborApr 30, 2008 10:03 am 
Eric LemingsApr 30, 2008 10:05 am 
Eric LemingsApr 30, 2008 1:07 pm 
Martin SeborApr 30, 2008 1:20 pm 
Eric LemingsApr 30, 2008 1:50 pm 
Eric LemingsApr 30, 2008 2:11 pm 
Martin SeborApr 30, 2008 3:27 pm 
Martin SeborApr 30, 2008 9:19 pm 
Farid ZaripovMay 14, 2008 8:50 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: ABI problem on DarwinActions
From:Martin Sebor (seb@roguewave.com)
Date:Apr 29, 2008 5:42:56 pm
List:org.apache.incubator.stdcxx-dev

Travis Vitek wrote:

Eric Lemings wrote:

Travis Vitek wrote:

Travis Vitek wrote:

Eric Lemings wrote:

Well I see one small problem already for which there is already a workaround. The BUILDDIR variable is assigned a value in makefile.in but it isn't set in the -install_name option when linking the library for some odd reason. In this case, the 4.2.0 workaround -- already documented I believe -- using DYDLD_LIBRARY_PATH is needed.

I didn't see that this was documented anywhere, but I did find some conversation on the topic in the archives. You can peruse that thread here [http://tinyurl.com/4saetr].

It looks like the original issue was never resolved. It seems to me that Martin is right, the build/test infrastructure should be setting DYLD_LIBRARY_PATH for shared builds just as it does for LD_LIBRARY_PATH on other platforms.

Slight problem with that. The required change would have to be made to a makefile that does not currently contain platform dependencies.

The two files I found that would need changes [they referenced LD_LIBRARY_PATH] were makefile.rules and GNUmakefile.cfg, both of which have at least one platform specific block.

Or we could just set DYLD_LIBRARY_PATH on all platforms though I doubt some will care for that. :)

That is what was done in one of the cases in the run block of GNUmakefile.cfg for LD_LIBRARY_PATH and LIBPATH. I don't see any motivating reason to avoid doing the same.

In my testing that seems to work just fine. You might have a look at the patch shown below.

Index: gcc.config =================================================================== --- gcc.config (revision 652071) +++ gcc.config (working copy) @@ -93,16 +93,13 @@ endif endif

-ifneq ($(OSNAME),Darwin) +ifeq ($(OSNAME),Darwin) # no -shared option for GCC on Mac OS X (Darwin) - LDSOFLAGS = -shared + LDSOFLAGS = -dynamiclib + LDSOFLAGS += -compatibility_version 4 -current_version $(LIBVER) else # Flags needed when linking the library - LDSOFLAGS = \ --dynamiclib \ --install_name $(BUILDDIR)/lib/$(LIBNAME) \ --compatibility_version 4 \ --current_version $(LIBVER) + LDSOFLAGS = -shared endif

Index: GNUmakefile.cfg =================================================================== --- GNUmakefile.cfg (revision 652071) +++ GNUmakefile.cfg (working copy) @@ -249,9 +249,10 @@ test -f $$file.o -a ! $$? -eq 0 ; \ else \ echo "./$$file" >>$(LOGFILE) ; \ + DYLD_LIBRARY_PATH=$$DYLD_LIBRARY_PATH:. ;

I don't think we want this. In fact, I don't even think we want to be setting LD_LIBRARY_PATH here because it's platform-specific too (HP-UX has SHLIB_PATH in addition to LD_LIBRARY_PATH, Solaris has LD_LIBRARY_PATH64 for 64-bit executables). I think we might be able to use GNU make's value function to parametrize GNUmakefile.cfg on a generic variable that we set in each .config file to the name of the corresponding variable on each platform. Like so:

# gcc.config ifeq ($(OSNAME),Darwin) LDPATHVAR := DYLD_LIBRARY_PATH else LDPATHVAR := LD_LIBRARY_PATH endif

# GNUmakefile.* $(value LDPATHVAR)=$(value $(value LDPATHVAR)):.; \ export $(value LDPATHVAR); \ ...

Martin