[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Update of sr#108201 (group libtool): Open/Closed:Open => Closed ___ Follow-up Comment #32: Did some digging and gcc appears to have solved the issue themselves[1]. >From GCC commit 6ee5892

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #31, sr #108201 (project libtool): apparently Joyent believe that this isn't closed, if there is somebody that has tested this too could determine whether or not to close the issue as fixed, thanks in advance. ___ Reply to

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #30, sr #108201 (project libtool): The following patch to export.at seems to work on solaris now testing for ELF in the shared object and using shrext_cmds to generate the .so extension. (file #27141) ___ Additional Item

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #29, sr #108201 (project libtool): There are currently many unapplied patches. Several of them are useful for Solaris. ___ Reply to this item at: __

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #28, sr #108201 (project libtool): On Thu 20 Dec 2012 04:48:06 GMT in comment #27 Richard PALO wrote: > When is the next release planned then? Soon. I had hoped to find time to do all the necessary testing before the end of the year, but with wedding and honeymoon to plan, at

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #27, sr #108201 (project libtool): This is fine with me. When *is* the next release planned then? In the meanwhile I will try to finish a pkgsrc patch to the already released bits (which seems to complain with auto* tools)... cheers

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #26, sr #108201 (project libtool): I have pushed the code changes to m4/Libtool.m4 (as two separate commits), but left the testsuite alone. Thank you for your work on this! I also added you to THANKS, I hope that was ok? A libtool release is not on my table though. Cheers, Pet

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #25, sr #108201 (project libtool): These are good arguments, I offer as well some observations and/or arguments before I sign off... 1. I thought about that last night, that *was* the advantage of elfdump, but not all ELF systems have elfdump and objdump is used instead! Perhaps

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #24, sr #108201 (project libtool): Hi again! I have no quarel with the original change to augment archive_expsym_cmds with ${wl}-h $wl$soname. That looks like a no-brainer as it just matches archive_cmds. That can go in at any time, as far as I'm concerned. The testsuite change

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #23, sr #108201 (project libtool): Since my original patch was in the vicinity, I suppressed $LDFLAGS as suggested, and it did get over the unsupported option problem. Decided to try the OBJDUMP flavor of SONAME test since libtool stores it in config (stolen from destdir.at). A

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #22, sr #108201 (project libtool): I had a look in the code and it is only for Solaris that old_archive_cmds and archive_cmds are rigged to include $LDFLAGS. This is clearly a buggy thing to do and it explains why -no-undefined is passed down to gcc for you. However, I have litt

Re: [sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

> Follow-up Comment #20, sr #108201 (project libtool): > There was a (substantially long) time where active libtool maintainers > were no longer able to bootstrap the project from git. Luckily that > issue was resolved so we are able to work with the master version > again and usefully apply we

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #21, sr #108201 (project libtool): Here is the git diff for master (apparently the same except for the file path). (file #27107) ___ Additional Item Attachment: File name: libtool.m4.git-diff-master Size:1 KB __

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Update of sr #108201 (project libtool): Operating System:*BSD => Solaris ___ Reply to this item at: ___

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #20, sr #108201 (project libtool): FYI, Peter Rosin is able to commit fixes to libtool. That is one reason why he focuses on the master version. Barring some severe nightmarish security defect, there will be no follow-on release based on the v2.4.2 sources. The next release wi

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #19, sr #108201 (project libtool): Well, I can certainly understand your reluctance to spend much more time on this, as I never really intended myself to do more than suggest a patch that fixes a libtool bug on solaris with gcc and solaris ld. Adding the test functionality is

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #18, sr #108201 (project libtool): I believe gcc 4.5.3 is the latest stable for Cygwin. I do not trust myself to be able to build a new gcc and verify that it actually works for Cygwin without investing far more time than I think is warranted. I imagine that there is some good re

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #17, sr #108201 (project libtool): I gather that your gcc is rather ancient (4.5.3 from april 2011) but I cannot determine which version of libtool you are using. Would it be possible to upgrade gcc to the latest 4.7.2 and git checkout v2.4.2 in order to update your repositor

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #16, sr #108201 (project libtool): I had an old git checkout from some time back (with some totally unrelated work in it) and I used that to run the export test. I'm not wasting hours on a full testsuite runs for this. I tested once configuring with CC=g++ and once with CC=gcc. B

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #15, sr #108201 (project libtool): could you please post your testsuite.log for the following command: gmake CC=g++ check-local it is possible that this is yet another bug (either in libtool or in gcc...) When I only run test 45 with gmake CC=g++ check-local TESTSUITEFLAG

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #14, sr #108201 (project libtool): Regarding the -no-undefined issue, I believe it is correct to set -no-undefined in LDFLAGS in export.at. This is the case since libtool is used to link in that test, and nothing else. Or is LDFLAGS special in some way on Solaris, so that it get

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #13, sr #108201 (project libtool): if the solaris developer/gnu-binutils or pkgsrc/devel/binutils is installed, then objdump is on the system. Just noticed that libtool's configure found objdump: richard@devzone:~/src/libtool$ grep objdump config* config.log:configure:5686: chec

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #12, sr #108201 (project libtool): perhaps to refine the test a bit more, would it be possible to check that the "value" of SONAME is the value expected. With elfdump, the SONAME could be extracted for example by: elfdump -d $soname | grep SONAME | awk '{printf $4}' Apparently

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #11, sr #108201 (project libtool): I guess I can add the following: 1. regarding "-no-undefined", when I changed this to avoid the syntax error on solaris (which should be, for example, -Wl,--no-undefined), the linker complained that it was a duplicate option implying, I believe

Re: [sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

On Wed, 12 Dec 2012, Peter Rosin wrote: Follow-up Comment #10, sr #108201 (project libtool): Dropping -no-undefined from LDFLAGS in export.at kills the test on Windows and it's unacceptable to assume that elfdump exists. Passing -no-undefined to libtool is NOT a misnomer and -no-undefined is in

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #10, sr #108201 (project libtool): Dropping -no-undefined from LDFLAGS in export.at kills the test on Windows and it's unacceptable to assume that elfdump exists. Passing -no-undefined to libtool is NOT a misnomer and -no-undefined is in fact a perfectly valid libtool option, not

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #9, sr #108201 (project libtool): BTW Bob, perhaps you didn't catch that I did a $git checkout v2.4.2 since it appears much has changed since the last stable. This is why, I believe, the tests indicate ## GNU Libtool 2.4.2 test suite. ##

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #8, sr #108201 (project libtool): Bob, please see comment #5 As I indicated, local test n° 45 export.at is the existing test. I added the following line : AT_CHECK([elfdump -d .libs/liba.so | grep "SONAME"],[], [ignore], [ignore]) to ensure that the SONAME was being added, e

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #7, sr #108201 (project libtool): Can you please re-post your patch as a file attachment? It seems that posting as a comment trashes the patch. Do any of the existing libtool test cases test the functionality you are fixing? Also, libtool.m4 is at m4/libtool.m4 in current git

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #6, sr #108201 (project libtool): And here is the diff for the proposed patch. After cleanup and rebuilding (seemed like a zillion autoreconfs) running the export tests as indicated (both for standard and CC=g++) are successful. richard@devzone:~/src/libtool$ git diff --staged d

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #5, sr #108201 (project libtool): Here is my feable and first attempt to detect the problem using the testsuite. First, the test export.at seems to work by default, but it is only a gcc (simple 'C') test: richard@devzone:~/src/libtool$ gmake check-local TESTSUITEFLAGS="45 -d" c

Re: [sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

On Tue, 11 Dec 2012, Dennis Clarke wrote: Follow-up Comment #2, sr #108201 (project libtool): I notice that the error message mentions the program name 'sed' rather than 'gsed'. Perhaps two different sed programs are being used? It seems likely that the 'sed' which failed is Solaris 'sed' rat

Re: [sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

- Original Message - From: Bob Friesenhahn Date: Tuesday, December 11, 2012 9:57 am Subject: [sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x To: Richard PALO , Bob Friesenhahn , libtool@gnu.org > Follow-up Comment #2, sr #108201 (project libt

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #4, sr #108201 (project libtool): I was working off of master. With git blame I noticed that the strcmp problem was introduced recently, so I'm trying over after git checkout v2.4.2, which is the latest tarball version I've tested with pkgsrc. HEAD is now at fdb4c54... Release 2

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #3, sr #108201 (project libtool): Hello Bob, I wonder too, which is why I indicated at the end of my last comment: > does libtool not like pkgsrc version of sed? > > richard@devzone:~/src/libtool$ which sed > /opt/pkg/gnu/bin/sed > richard@devzone:~/src/libtool$ grep 'SED=' con

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #2, sr #108201 (project libtool): I notice that the error message mentions the program name 'sed' rather than 'gsed'. Perhaps two different sed programs are being used? It seems likely that the 'sed' which failed is Solaris 'sed' rather than GNU 'sed'.

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

Follow-up Comment #1, sr #108201 (project libtool): trying to bootstrap git base to provide a test case and patch proposal, but I notice some problems already in doing after ./bootstrap && ./configure gmake check syntax-check distcheck ## - ## ## Test results. ## ## ---

[sr #108201] libtool problems with -export-symbols-regex on solaris with gcc-4.7.x

URL: Summary: libtool problems with -export-symbols-regex on solaris with gcc-4.7.x Project: GNU Libtool Submitted by: risto3 Submitted on: lun. 10 déc. 2012 13:58:02 GMT Category: