incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: ABI problem on Darwin
Date Wed, 30 Apr 2008 00:43:19 GMT
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

Mime
View raw message