Opened 13 years ago

Closed 12 years ago

Last modified 11 years ago

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

libtool-Portfile.diff (410 bytes) - added by titus@… 13 years ago.
Diff for the port file
ltmain.m4sh-allow-clang-stdlib.diff (804 bytes) - added by titus@… 13 years ago.
patch for ltmain.m4sh

Download all attachments as: .zip

Change History (14)

Changed 13 years ago by titus@…

Attachment: libtool-Portfile.diff added

Diff for the port file

Changed 13 years ago by titus@…

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

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 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 in reply to:  3 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:5 Changed 13 years ago by anddam (Andrea D'Amore)

Cc: and.damore@… added

Cc Me!

comment:6 Changed 12 years ago by titus@…

The patch has been committed upstream in February.

http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commit;h=c0c49f289f22ae670066657c60905986da3b555f

Do you still have any objections? Otherwise I'd commit it.

comment:7 in reply to:  6 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: assignedclosed

patch committed in r93788.

comment:9 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 in reply to:  9 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.

comment:12 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.