[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:

[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

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 #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 #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

[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 #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 #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 #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

[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 #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 #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 #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 #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 #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

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 #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 #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 #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 #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

Re: g++ and -nostdlib

Le 06/12/13 09:51, Peter Rosin a écrit : [dropping libtool-patches@] On 2013-11-12 12:24, Peter Rosin wrote: [re-adding libtool@] On 2013-11-11 16:10, Bob Friesenhahn wrote: On Mon, 11 Nov 2013, Peter Rosin wrote: Quite a lot of effort went into making this work the way it currently does.

Re: g++ and -nostdlib

I already have a question to see this through: Does it sound reasonable to add support to inherit_linker_flags '-fstack-protector|-fstack-protector-all' in a similar manner to '-pthreads' given the compiler needs to have this option in order to include the correct libraries... __

Re: g++ and -nostdlib

Le 22/01/14 17:54, Richard PALO a écrit : I already have a question to see this through: Does it sound reasonable to add support to inherit_linker_flags '-fstack-protector|-fstack-protector-all' in a similar manner to '-pthreads' given the compiler needs to have this option

Re: g++ and -nostdlib

Le 09/11/13 07:44, Richard PALO a écrit : I believe Chuck is oriented in the right direction. A good example is with -fstack-protector. gcc/g++ knows how to link depending upon whether the platforms libc has SSP support or not. I doubt very much that libtool wants to figure out whether to add

Re: [RFC] any critical patches for a release this weekend?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 23/10/14 21:10, Gary V. Vaughan a écrit : > I plan to roll a release based off the v2.4.2 tag, incorporating > fixes for version mismatches against Mac OS Yosemite this weekend - > in consideration of the fact that there are still known regressions

[sr #108987] libtool doesn't like simple RM defined (without options)

URL: Summary: libtool doesn't like simple RM defined (without options) Project: GNU Libtool Submitted by: risto3 Submitted on: dim. 28 févr. 2016 14:20:46 GMT Category: None

[sr #108987] libtool doesn't like simple RM defined (without options)

Follow-up Comment #1, sr #108987 (project libtool): another simple, but enlightening way to see this is $ env RM=/usr/bin/rm gmake or $ env RM=/usr/bin/rm gmake check it appears to be more involved than simply updating '${RM}r' to '${RM} -r' in ltmain.in ___

[sr #108987] libtool doesn't like simple RM defined (without options)

Follow-up Comment #2, sr #108987 (project libtool): It appears that the shell assignment expectation may be erroneous, in that ": ${RM="rm -f"}" will only replace RM if RM is not defined. perhaps what is intended is more along the lines of: RM="${RM:=rm} -f" (NB it would probably be easier to co

[sr #108987] libtool doesn't like simple RM defined (without options)

Follow-up Comment #3, sr #108987 (project libtool): The attached patchsets seem to get over the issue for RM, as well as for eventual problems for CP or MV. the first patchset (0001-*) is for the master libtool repo, and the second (0002-*) is for gl-mod/bootstrap in order to generate the new bo

[sr #108987] libtool doesn't like simple RM defined (without options)

Additional Item Attachment, sr #108987 (project libtool): File name: 0001-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch Size:1 KB File name: 0002-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch Size:0 KB ___ Reply t

avoid issues if CP, MV or RM are predefined in the execution environment

7;fixes' the use as documented, that is to respect the environment if these variables are set, but naturally -- if set -- they will be just the path to the tool and as such can in no way expect that '-f' is specified (which is '--force' under the Gnu