RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, April 28, 2008 10:45 PM > To: dev@stdcxx.apache.org > Subject: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release) > > I see three options for how to deal with the ABI breakage on > Darwin: > >1) fix/revert the change that causes the ABI breakage, > create new release candidate, and start a new vote, or I'll manually revert the change for STDCXX-488 and test it again today though I have a feeling its not going to fix this. If it doesn't, we'll have to go with one of the other two options. Brad.
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, April 28, 2008 10:45 PM > To: dev@stdcxx.apache.org > Subject: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release) > ... > > Let me know your thoughts. Darwin is not currently listed as a primary OR a secondary platform but a "best effort" platform, isn't it? If so, this problem shouldn't hold up the 4.2.1 release IMHO. Then again, I'm not the release manager for 4.2.1. :) Your call. Brad.
RE: ABI test results with MSVC 8.0/Windows XP-64bit/12d
> >-Original Message- > >From: Farid Zaripov [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, April 22, 2008 5:27 AM > >To: dev@stdcxx.apache.org > >Subject: ABI test results with MSVC 8.0/Windows XP-64bit/12d > > > >msvc 8.0/WinXP-64bit/12d SRC: 4.2.0 4.2.0 4.2.1 4.2.1 > > LIB: 4.2.0 4.2.1 4.2.0 4.2.1 > >limits DIFF 0 > >random_shuffle 0DIFF > >21.string.io.stdcxx-250 ABRTNOUT > >21.string.stdcxx-231 ABRTNOUT > >22.locale.ctype.is331 0 > >22.locale.ctype.narrow 0 381 5 0 > >22.locale.num.put 96 24 > >22.locale.num.put.stdcxx-2 ABRTNOUT > >27.basic.ios.copyfmt.stdcxx-766 ABRTNOUT > >27.ostream.unformatted.stdcxx-626ABRTNOUT > >27.ostream 2 0 2 0 > >27.streambuf.imbue.stdcxx-307ABRTNOUT > >27.stringbuf.overflow.stdcxx-795 ABRTNOUT > > > > > > The results in 15d configuration and on icc 10.0 in 12d > and 15d are > >the same. > > > >Farid. > > > > I'm curious what it means when nothing is shown in a cell. > i.e. what were the results of the limits test for the last > two configurations? Actually I have compared the src/lib pairs 4.2.0/4.2.0 vs 4.2.0/4.2.1 only and then 4.2.1/4.2.1 vs 4.2.1/4.2.0 only. So empty cells means that the results has not changed due to replacing the library file. As for the limits example results, I missed that the results has changed. Here the results for limits: msvc 8.0/WinXP-64bit/12d SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 limits DIFF 0DIFF 0 Farid.
RE: [VOTE] stdcxx 4.2.1 release
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, April 28, 2008 10:01 AM > To: dev@stdcxx.apache.org > Subject: Re: [VOTE] stdcxx 4.2.1 release > > Eric Lemings wrote: > > > > There are some link errors in the tests on Solaris, one of > which is the > > new 22.locale.synopsis test which, I was under the > impression was not to > > be included in this patch release (along with the other migrated > > tests). > > It's not included. Are you sure you tested the release candidate > tarball and not something else? > > $ wget -q > http://people.apache.org/~sebor/stdcxx-4.2.1-rc-3/stdcxx-4.2.1 > .tar.gz && > gunzip -c stdcxx-4.2.1.tar.gz | tar -tvf - | grep > 22\.locale\.synopsis > || echo NOT FOUND > NOT FOUND That was it. I must have been testing a previous release candidate. In the test that I just did on Solaris, I found only the link error for the 26.valarray.binary.stdcxx-237 test that is being reported in the nightly test results. http://people.apache.org/~sebor/stdcxx/results/builds/solaris-10-sparc-s unpro-5.9.html Brad.
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
The workaround is to remove the link flags for version info (i.e. -compatibility_version and -current_version) from the file etc/config/gcc.config. This takes care of the runtime link error. There are some other link flags that could/should probably be added (e.g. -Wl,-undefined, -Wl,dynamic_lookup, -Wl,-single_module) but that's a post-4.2.1 change. I'd also to figure out why the version info flags were working before now at some point. Brad. > -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Monday, April 28, 2008 10:45 PM > To: dev@stdcxx.apache.org > Subject: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release) > > I see three options for how to deal with the ABI breakage on > Darwin: > >1) fix/revert the change that causes the ABI breakage, > create new release candidate, and start a new vote, or > >2) document the breakage and a workaround in the README, > create a new release candidate, and start a new vote, or > >3) open an issue for the ABI breakage, document how to work > around it, but release -rc-3 unchanged. > > If the problem is due to STDCXX-488 (1) should be pretty easy > to do and we could start the vote as early as tomorrow night, > and that would be my preference. Assuming the fix is isolated > to gcc/Darwin specific areas of the build infrastructure the > amount of re-testing would be small. > > If it isn't easily fixable or if the fix is risky, we could > do (2) and still get the vote going by the end of tomorrow. > Fixing a README is trivial so the amount of retesting would > be minimal. > > I'm not wild about option (3) because it goes against our > binary compatibility policy but given that Darwin is a best > effort platform I could be convinced to go with it if none > of the other alternatives was viable. It also is the most > expeditious approach. > > Let me know your thoughts. > > Martin Sebor wrote: > > Eric Lemings wrote: > >> > >> On Apr 28, 2008, at 10:00 AM, Martin Sebor wrote: > >>> Does this mean that stdcxx 4.2.1 isn't binary compatible with > >>> 4.2.0 on Darwin or that there is a problem with a dependency > >>> on some system library or something like that? (I can't tell > >>> for sure from the output you pasted below.) Either way, is > >>> this something new? (I don't recall it being mentioned when > >>> we did our binary compatibility testing two weeks ago.) > >> > >> It's most likely a problem with the way the library is built. > > > > Could STDCXX-488 have something to do with it? > > http://issues.apache.org/jira/browse/STDCXX-488 > > > >> > >> The first time I saw it was a couple weeks ago while > testing binary > >> compatibility. > > > > And you waited to mention it until now because...? > > > > > >
RE: Binary compatibility test results for Sun C++ 5.8 on Solaris 8 and 10 platforms
Reformatted to conform with other binary test results: http://people.apache.org/~elemings/compat-test-results/solaris-8-compat- results http://people.apache.org/~elemings/compat-test-results/solaris-10-compat -results HTH. Brad. > -Original Message- > From: Eric Lemings [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 22, 2008 5:23 PM > To: dev@stdcxx.apache.org > Subject: Binary compatibility test results for Sun C++ 5.8 on > Solaris 8 and 10 platforms > > > http://people.apache.org/~elemings/compat-test-results/ > > The diff files summarize the differences between the baseline tests > (i.e. matching lib and test versions) and the compat tests (i.e. > different lib and test versions) respectively. chess is a Solaris 10 > machine. antlia is a Solaris 8 machine. > > All in all, no real big problems that I see. > > Brad. > >
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
>Eric Lemings wrote: > >The workaround is to remove the link flags for version info (i.e. >-compatibility_version and -current_version) from the file >etc/config/gcc.config. This takes care of the runtime link error. We should probably commit the fix to 4.2.x to get the ball rolling. > >There are some other link flags that could/should probably be added >(e.g. -Wl,-undefined, -Wl,dynamic_lookup, -Wl,-single_module) but >that's a post-4.2.1 change. I'd also to figure out why the version >info flags were working before now at some point. I looked at the patch http://tinyurl.com/3p4385, I'm thinking that we don't want the -install_name flag either. If I understand what it does, it is different than the -rpath flag in that it is applied to the shared library itself and not the executables that link to it. The install_name associated with the library tells the runtime linker where the library is allowed to be found, so once you've tagged a shared library with an install_name that is an absolute path that library can never be moved without modifying the install_name. I found some discussion on this flag was found on the boost list here [http://tinyurl.com/3hxjjm]. Here is a snippet. [quote] > > And why does OSX embed the path? Standard GNU tools will only > embed "soname" -- which is a name embedded in a shared library > that tells by what name other libraries should refer to it. > Is something like that present on OSX? Right, this is called the "install_name" for dylibs. It can be a file name or an entire path or some "special paths" like "@executable_path/../". When one library links to another this "install_name" is used so that all the libraries and executables know how to find each other. An example should clarify this. libA.dylib has an "install_name" of "libA.dylib" libB.dylib has an "install_name" of "/Users/Shared/Sandbox/lib/libB.dylib" libC.dylib has an "install_name" of "@executable_path/../lib/libC.dylib" Now we have an executable called foo that links against all three libraries. In order for foo to run successfully, libA.dylib must be in a folder defined in the DYLD_LIBRARY_PATH, libB must be located in /Users/Shared/Sandbox/lib/ and libC must be located in a "../lib/" which is a directory that is relative to foo. That, in a nutshell is how OS X linking works. [/quote] Is this something that we want? Travis
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 29, 2008 12:10 PM > To: dev@stdcxx.apache.org > Subject: RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx > 4.2.1 release) > > > > >Eric Lemings wrote: > > > >The workaround is to remove the link flags for version info (i.e. > >-compatibility_version and -current_version) from the file > >etc/config/gcc.config. This takes care of the runtime link error. > > > We should probably commit the fix to 4.2.x to get the ball rolling. Hold up on that. I've found the problem may actually have been the result of an anomoly in my environment. I suspect I may have had another version of the library installed in a standard location which is why the observation I posted was so puzzling. My latest builds are running fine. Brad.
RE: [VOTE] stdcxx 4.2.1 release
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Friday, April 25, 2008 7:45 AM > To: dev@stdcxx.apache.org > Cc: [EMAIL PROTECTED] > Subject: [VOTE] stdcxx 4.2.1 release > > Please download and test the tarball on a platform of your > choice, and send in your vote on this release candidate. In > your vote, please identify the platform(s), their versions, > and the stdcxx configurations you tested. I tested on 32-bit and 64-bit MSVC 8.0 and ICC 10.0 in 12d/12D build type and also in MSVC 7.1/12d. The results are available here: http://people.apache.org/~faridz/build_msvc-8.0-12d.log http://people.apache.org/~faridz/build_msvc-8.0-x64-12d.log http://people.apache.org/~faridz/build_icc-10.0-12d.log http://people.apache.org/~faridz/build_icc-10.0-x64-12d.log http://people.apache.org/~faridz/build_msvc-7.1-12d.log I have created some new issues for failing tests. My vote is: +1. Farid.
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 29, 2008 12:10 PM
> To: dev@stdcxx.apache.org
> Subject: RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx
> 4.2.1 release)
>
>
...
>
> Is this something that we want?
Yeah after futher deliberation, I think you're right. We probably don't
want to specify the full path name and either omit the path altogether
or use the @executable_path form.
Question though. Is the STDCXX library relocatable (in terms of install
directory) on other platforms?
I do know that Darwin/MacOS X packages ("bundles" they're called) are
installed and work quite a bit differently than most other Unix OSes.
On most Unix systems, hypothetical package `Foo` distributed with
install files `bin/foo`, `lib/libfoo.so`, and `include/foo.h` are
usually installed in /usr or /usr/local (or some other standard
location) along with many other package files. The equivalent package
on Darwin/MacOS X would be installed in its own package directory: e.g.
`/Applications/Foo/bin/foo`, `/Applications/Foo/lib/libfoo.so` (with a
.dylib link), and `/Applications/Foo/include/foo.h`.
Brad.
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
>Eric Lemings wrote:
>
>> Travis Vitek wrote:
>>
>> Is this something that we want?
>
>Yeah after futher deliberation, I think you're right.
>We probably don't want to specify the full path name
>and either omit the path altogether or use the
>@executable_path form.
>
>Question though. Is the STDCXX library relocatable (in terms
>of install directory) on other platforms?
Yes. If the platform requires that the library be available at the
location provided to -rpath, then the path that the library is at when
the application is build must remain the same, but I believe that most
platforms fall back to LD_LIBRARY_PATH (or equivalent) if the library is
not found in the directory specified with -rpath.
Martin may have more information on this.
>I do know that Darwin/MacOS X packages ("bundles" they're called) are
>installed and work quite a bit differently than most other Unix OSes.
>On most Unix systems, hypothetical package `Foo` distributed with
>install files `bin/foo`, `lib/libfoo.so`, and `include/foo.h` are
>usually installed in /usr or /usr/local (or some other standard
>location) along with many other package files. The equivalent package
>on Darwin/MacOS X would be installed in its own package directory: e.g.
>`/Applications/Foo/bin/foo`, `/Applications/Foo/lib/libfoo.so` (with a
>.dylib link), and `/Applications/Foo/include/foo.h`.
>
Bundles are essentially application installs. The include the
application and any resources [libraries, headers, images, ...] that
they are intended to work with. When dealing with an application
installation it makes a little sense to require that the library is in a
specific location or relative to the executable. It appears to be an
attempt to avoid the unix version of 'dll hell' where multiple versions
of the same library have to coexist.
Travis
>Brad.
>
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
>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. > >Brad. Yes, it looks like users will see failures because of the -install_name linker option if things are left as-is. I did a clean build on OSX and I get the following error message when trying to run any of the utilities, tests or examples. $ ./vector dyld: Library not loaded: /lib/libstd12d.dylib Referenced from: /private/tmp/vitek/stdcxx-4.2.1/build/tests/./vector Reason: image not found $ export DYLD_LIBRARY_PATH=/tmp/vitek/stdcxx-4.2.1/build/lib $ ./vector dyld: Library not loaded: /lib/libstd12d.dylib Referenced from: /private/tmp/vitek/stdcxx-4.2.1/build/tests/./vector Reason: image not found $ export DYLD_LIBRARY_PATH=/tmp/vitek/stdcxx-4.2.1/build $ ./vector dyld: Library not loaded: /lib/libstd12d.dylib Referenced from: /private/tmp/vitek/stdcxx-4.2.1/build/tests/./vector Reason: image not found Since the absolute path /lib/libstd12d.dylib is hard-coded into the libraries install_name, the dynamic linker won't load the libstd12d.dylib that is found in the DYLD_LIBRARY_PATH. I modified makefile.in to use '-install_name libstd12d.dylib' in hopes that it would work, but I get the same result. The only way that I was able to get something to work was to remove the -install_name flag from the library link line and then use DYLD_LIBRARY_PATH so that the system would find it. I'm doing a rebuild now to make absolutely sure that everything is working as expected. Travis
RE: [jira] Commented: (STDCXX-866) add 22.locale.ctype.widen.cpp
Now that I've looked closer at both tests, I think you're right: the
22.locale.ctype.narrow tests already exercises everything in the
22.locale.ctype.widen test. Question is, do we want to just remove the
22.locale.ctype.widen test and leave the narrow test as it is or split
the narrow test into narrow and widen counterparts?
More generally, do we plan to integrate these new tests into subsequent
4.2.x releases or should they wait for 4.3?
Brad.
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 28, 2008 2:40 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [jira] Commented: (STDCXX-866) add
> 22.locale.ctype.widen.cpp
>
> Brad, I've reopened the issue until we know that the new test
> really is needed (i.e., that it exercises functionality that's
> not also tested by 22.locale.ctype.narrow.cpp).
>
> Martin Sebor wrote:
> > Brad,
> >
> > You probably missed my question below: do we really need this test?
> >
> > Martin
> >
> > Martin Sebor (JIRA) wrote:
> >> [
> >>
> https://issues.apache.org/jira/browse/STDCXX-866?page=com.atla
> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focus
> edCommentId=12590141#action_12590141
> >> ]
> >> Martin Sebor commented on STDCXX-866:
> >> -
> >>
> >> I just noticed that
> >>
> [{{22.locale.ctype.narrow.cpp}}|http://svn.apache.org/repos/as
> f/stdcxx/trunk/tests/localization/22.locale.ctype.narrow.cpp]
> >> also exercises {{ctype::widen()}}. Does this new test do anything
> >> {{22.locale.ctype.narrow.cpp}} doesn't?
> >>
> >>> add 22.locale.ctype.widen.cpp
> >>> -
> >>>
> >>> Key: STDCXX-866
> >>> URL:
> https://issues.apache.org/jira/browse/STDCXX-866
> >>> Project: C++ Standard Library
> >>> Issue Type: Sub-task
> >>> Components: Tests
> >>>Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0
> >>>Reporter: Martin Sebor
> >>> Fix For: 4.2.1
> >>>
> >>> Attachments: 22.locale.ctype.widen.cpp, 22_ctype_widen.cpp
> >>>
> >>> Original Estimate: 2h
> >>> Time Spent: 1h
> >>> Remaining Estimate: 1h
> >>>
> >>> The test 22_ctype_widen.cpp needs to be migrated from the
> Rogue Wave
> >>> source code repository into Subversion under the name
> >>>
> [localization/22.locale.ctype.widen.cpp|http://svn.apache.org/
> repos/asf/stdcxx/trunk/tests/localization/22.locale.ctype.widen.cpp].
> >>>
> >>
> >
>
>
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
>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.
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
> -Original Message- > From: Travis Vitek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 29, 2008 3:16 PM > To: dev@stdcxx.apache.org > Subject: RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx > 4.2.1 release) > > > > >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. Or we could just set DYLD_LIBRARY_PATH on all platforms though I doubt some will care for that. :) Brad.
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
>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:. ;
\
LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:. ;
\
LIBPATH=$$LIBPATH:. ;
\
- export LIBPATH LD_LIBRARY_PATH ;
\
+ export LIBPATH LD_LIBRARY_PATH DYLD_LIBRARY_PATH;
\
text=`./$$file` ;
\
fi;
\
res=$$? ;
\
Index: makefile.rules
===
--- makefile.rules (revision 652071)
+++ makefile.rules (working copy)
@@ -135,7 +135,9 @@
# produce a .out file by running the executable
%.out: %
- LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR) ./$< >$@ 2>&1
+ LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR)
\
+DYLD_LIBRARY_PATH=$$DYLD_LIBRARY_PATH:$(LIBDIR)
\
+./$< >$@ 2>&1
# create a script that when run first builds the executable and then
runs it
# done to save even more space than `NO_DOT_O' on constrained systems
@@ -165,6 +167,7 @@
run runall run_all: $(BINDIR)/exec
@(LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR);
\
+DYLD_LIBRARY_PATH=$$DYLD_LIBRARY_PATH:$(LIBDIR);
\
PATH=$$PATH:.;
\
TOPDIR=$(TOPDIR);
\
TMPDIR=$${TMPDIR:-/tmp}/stdcxx-run-;
\
Here are the build results I got with that patch. Last four columns have
been omitted to avoid line wraps.
NAME STATUS WARN ASSERTS FAILED
0.alloc 00 0 0
0.braceexp NOUT0
0.char08 479 4
0.cmdoptsFORMAT0
0.ctype 0 303313 0
0.fnmatch NOUT0
0.inputiter 00 20 0
0.new 00 26 0
0.outputiter 00 0 0
0.printfBUS0
0.process 00 17 0
0.strncmpFORMAT0
0.valcmp FORMAT0
17.extensions 00 16 5
17.names
RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx 4.2.1 release)
Looks fine to me. If no one objects to setting DYLD_LIBRARY_PATH on
all Unix platforms, I say we go with it. Is is more consistent with
the way runtime linking works on other Unix-like platforms after all.
Brad.
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 29, 2008 5:20 PM
> To: dev@stdcxx.apache.org
> Subject: RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx
> 4.2.1 release)
>
>
>
> >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:. ;
> \
>LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:. ;
> \
>LIBPATH=$$LIBPATH:. ;
> \
> - export LIBPATH LD_LIBRARY_PATH ;
> \
> + export LIBPATH LD_LIBRARY_PATH DYLD_LIBRARY_PATH;
> \
>text=`./$$file` ;
> \
>fi;
> \
>res=$$? ;
> \
> Index: makefile.rules
> ===
> --- makefile.rules(revision 652071)
> +++ makefile.rules(working copy)
> @@ -135,7 +135,9 @@
>
> # produce a .out file by running the executable
> %.out: %
> - LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR) ./$< >$@ 2>&1
> + LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR)
> \
> +DYLD_LIBRARY_PATH=$$DYLD_LIBRARY_PATH:$(LIBDIR)
> \
> +./$< >$@ 2>&1
>
> # create a script that when run first builds the executable and then
> runs it
> # done to save even more space than `NO_DOT_O' on constrained systems
> @@ -165,6 +167,7 @@
>
> run runall run_all: $(BINDIR)/exec
> @(LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(LIBDIR);
> \
> +DYLD_LIBRARY_PATH=$$DYLD_LIBRARY_PATH:$(LIBDIR);
> \
> PATH=$$PATH:.;
> \
> TOPDIR=$(TOPDIR);
> \
> TMPDIR=$${TMPDIR:-/tmp}/stdcxx-run-;
> \
>
>
> Here are the build results I got with that patch. Last four
> columns have
> been omitted to avoid line wraps.
>
> NAME STATUS WARN ASSERTS FAILED
> 0.alloc 00 0 0
> 0.braceexp NOUT0
> 0.char08 479 4
> 0.cmdopts
[Fwd: SVN write-access enabled again =)]
FYI: Original Message Subject: SVN write-access enabled again =) Date: Tue, 29 Apr 2008 22:14:26 +0200 From: Norman Maurer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi folks, we finally managed to get the replacement for eris ( svn.apache.org ) online. SVN is now served via a brand new Dell PowerEdge 2950. All SVN data were migrated from the old server without any data-loss. Thx to the whole Infrastructure Team for the nice team work, and to the community for the patience =) Cheers, Norman
Re: ABI problem on Darwin
Travis Vitek wrote: Eric Lemings wrote: The workaround is to remove the link flags for version info (i.e. -compatibility_version and -current_version) from the file etc/config/gcc.config. This takes care of the runtime link error. We should probably commit the fix to 4.2.x to get the ball rolling. There are some other link flags that could/should probably be added (e.g. -Wl,-undefined, -Wl,dynamic_lookup, -Wl,-single_module) but that's a post-4.2.1 change. I'd also to figure out why the version info flags were working before now at some point. I looked at the patch http://tinyurl.com/3p4385, I'm thinking that we don't want the -install_name flag either. We definitely don't want to be hardcoding BUILDDIR into the lib, no matter what it does. BUILDDIR is a temporary directory that most likely disappears as soon as the library's installed. If I understand what it does, it is different than the -rpath flag in that it is applied to the shared library itself and not the executables that link to it. Right. Rpath is just a convenience for us so that we can easily run programs without setting LD_LIBRARY_PATH. The install_name associated with the library tells the runtime linker where the library is allowed to be found, so once you've tagged a shared library with an install_name that is an absolute path that library can never be moved without modifying the install_name. That could be used in the install target (or if the INSTALLDIR variable is set). Martin I found some discussion on this flag was found on the boost list here [http://tinyurl.com/3hxjjm]. Here is a snippet. [quote] And why does OSX embed the path? Standard GNU tools will only embed "soname" -- which is a name embedded in a shared library that tells by what name other libraries should refer to it. Is something like that present on OSX? Right, this is called the "install_name" for dylibs. It can be a file name or an entire path or some "special paths" like "@executable_path/../". When one library links to another this "install_name" is used so that all the libraries and executables know how to find each other. An example should clarify this. libA.dylib has an "install_name" of "libA.dylib" libB.dylib has an "install_name" of "/Users/Shared/Sandbox/lib/libB.dylib" libC.dylib has an "install_name" of "@executable_path/../lib/libC.dylib" Now we have an executable called foo that links against all three libraries. In order for foo to run successfully, libA.dylib must be in a folder defined in the DYLD_LIBRARY_PATH, libB must be located in /Users/Shared/Sandbox/lib/ and libC must be located in a "../lib/" which is a directory that is relative to foo. That, in a nutshell is how OS X linking works. [/quote] Is this something that we want? Travis
Re: ABI problem on Darwin
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
Re: ABI problem on Darwin
Travis Vitek wrote: Eric Lemings wrote: The workaround is to remove the link flags for version info (i.e. -compatibility_version and -current_version) from the file etc/config/gcc.config. This takes care of the runtime link error. We should probably commit the fix to 4.2.x to get the ball rolling. I agree. Reverting the problematic patch seems like the safest way to proceed for 4.2.1. Let's plan on fixing the "rpath" issue the right way in 4.2.2. Martin
