#32982 closed enhancement (fixed)
libtool-2.4.2: patch to allow -stdlib=* as linker flags
| Reported by: | titus@… | Owned by: | skymoo (Adam Mercer) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.0.3 |
| Keywords: | Cc: | anddam (Andrea D'Amore), cooljeanius (Eric Gallager) | |
| Port: | libtool |
Description
Building a libtoolized project using clang++ and libc++ fails because libtool does not pass -stdlib=<xx> to the linker command.
The attached patch file enables this option in libtool.
Attachments (2)
Change History (14)
Changed 13 years ago by titus@…
| Attachment: | libtool-Portfile.diff added |
|---|
Changed 13 years ago by titus@…
| Attachment: | ltmain.m4sh-allow-clang-stdlib.diff added |
|---|
patch for ltmain.m4sh
comment:1 Changed 13 years ago by titus@…
I've sent this patch to bug-libtool@… as described in
http://www.gnu.org/software/libtool/manual/libtool.html#Stripped-link-flags
comment:2 Changed 13 years ago by skymoo (Adam Mercer)
| Cc: | ram@… removed |
|---|---|
| Owner: | changed from macports-tickets@… to ram@… |
| Status: | new → assigned |
What errors do you get as I've build several libtool based projects using clang++ and didn't encounter issues. Granted they where mainly written in c, but did have several c++ components.
I've looked at the archive for the bug-libtool list and can't see your email, let me know what response you get from upstream.
comment:3 follow-up: 4 Changed 13 years ago by titus@…
It's simply that libtool filters linker options that are unknown to it.
It refuses to pass -stdlib=libc++ to clang++ as the linker. No macport uses this up to now, but it's necessary for my software. I've just sent some general questions about that to the mailing list.
A simple test is to try to compile cppunit with libc++:
tar xzf /opt/local/var/macports/distfiles/cppunit/cppunit-1.12.1.tar.gz cd cppunit-1.12.1 autoreconf -fvi export CC=clang export CXX=clang++ export CXXFLAGS=-libstdc++ export LDFLAGS=-libstdc++ ./configure make
This fails during linking the dylib because for compilation libc++ header files get used, but for linking the flag is dropped by libtool, so clang++ tries to link to libstdc++, which of course has to fail.
After modifying libtool with the patch, and executing "autoreconf -fvi" before ./configuring cppunit, the dylib linking step is ok.
I don't know why the mail to gnu.org does not show up.
Is it a moderated list? Do I have to subscribe to something? Did you successfully post to this address?
My server says
Jan 22 13:30:40 postfix/smtp[37774]: D8B951C583E1: to=<bug-libtool@gnu.org>, relay=eggs.gnu.org[140.186.70.92]:25, status=sent (250 OK id=1RowZE-000499-DT)
comment:4 Changed 13 years ago by skymoo (Adam Mercer)
Replying to titus@…:
It refuses to pass -stdlib=libc++ to clang++ as the linker. No macport uses this up to now, but it's necessary for my software. I've just sent some general questions about that to the mailing list.
When are you hoping to submit the ports that require this?
The reason I'm asking is that I'm not very familiar with the libtool internals and am worried about this having adverse effects. Let's give upstream chance to weigh in.
I don't know why the mail to gnu.org does not show up.
It's there now: http://lists.gnu.org/archive/html/bug-libtool/2012-01/msg00019.html, lets see what upstream says.
comment:6 follow-up: 7 Changed 12 years ago by titus@…
The patch has been committed upstream in February.
Do you still have any objections? Otherwise I'd commit it.
comment:7 Changed 12 years ago by skymoo (Adam Mercer)
Replying to titus@…:
Do you still have any objections? Otherwise I'd commit it.
No, if upstream are happy then that is good enough for me. Feel free to commit the changes as I'm swamped at the moment and don't know when I'll have the time to take a look. Make sure you bump the revision as the attached patch doesn't do this.
comment:8 Changed 12 years ago by titus@…
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
patch committed in r93788.
comment:9 follow-up: 11 Changed 12 years ago by jmroot (Joshua Root)
You should really patch whichever file(s) are generated from ltmain.m4sh instead, to avoid the need to run autoconf.
comment:10 Changed 12 years ago by jmroot (Joshua Root)
Looks like that would be libltdl/config/ltmain.in.
comment:11 Changed 12 years ago by titus@…
Replying to jmr@…:
You should really patch whichever file(s) are generated from ltmain.m4sh instead, to avoid the need to run autoconf.
Normally, patching generated files is idea: If you are absolutely sure that the generated files do not need to be regenerated and are always guaranteed to be up to date in the distribution *then* that might be ok. Otherwise it's just luck that autoconf hasn't been needed up to now.
Since I'm not so sure about this, adding autoconf seems to me to be the safer way.
Diff for the port file