BUG: libtool-1.5.X / 1.9.X is broken on OS X 10.4.6 / MacBook Pro

[armando@…]

I've installed, cleaned out, reinstalled, retested libtool versions 1.5.X and libtool-devel (1.9.X) and both have similar behavior. Basically, the generated libtool script is completely broken, as in about 6 spots, what should be a new line is instead a "~".

The following is from libtool-devel, but the same exact thing happened in 1.5.X series. ~line 116:

---

# Commands used to install an old-style archive. RANLIB="ranlib" old_postinstall_cmds="\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds=""

---

~line 234

---

# Commands used to build an old-style archive. old_archive_cmds="\$AR \$AR_FLAGS \$oldlib\$oldobjs\$old_deplibs~\$RANLIB \$oldlib"

---

~line 275

---

# Commands used to build a shared archive. archive_cmds="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring" archive_expsym_cmds="sed -e
\"s,#.*
\" -e
\"s,[ ]*
\" -e
\"s,

(..*

),_&,
\" < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring~nmedit -s \$output_objdir/\${libname}-symbols.expsym \${lib}"

# Commands used to build a loadable module if different from building # a shared archive. module_cmds="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs\$compiler_flags" module_expsym_cmds="sed -e
\"s,#.*
\" -e
\"s,[ ]*
\" -e
\"s,

(..*

),_&,
\" < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs\$compiler_flags~nmedit -s \$output_objdir/\${libname}-symbols.expsym \${lib}"

---

... as you can see, there are problems where programs like chmod, $RANLIB, $CC, nmedit are trying to be run, seemingly, but there is a "~" instead of a new-line.

I will attach the entire file in the first comment if it lets me (this is my first time bug reporting here).

[armando@…]

The entire broken glibtool file from libtool-devel

[armando@…]

Just to note it somewhere, a suitable work around is:

• port install libtool (installs glibtool, glibtoolize)
• ln -s /opt/local/bin/glibtoolize /opt/local/bin/libtoolize

The system libtool works, and libtoolize is available ... so far, nothing has failed compiling with this setup (gstreamer 0.10.X, liboil, etc).

[armando@…]

My assumption when I posted this bug is that it was "really bad." Considering it has had no updates from anyone else (who probably knows more than I do), I have to wonder if it is.

So, I have a question: is this not a major and really bad bug? If not, how are other people who use darwin ports and develop other software using libtool? Comment #2 below explains what I do to seemingly get around the issue, but I am not convinced that method is 100% correct.

Any information would be appreciated.

[rhwood@…]

I am using the Apple provided libtool scripts instead of the DP provided scripts, which generally is a very good idea if Apple's XCode-bundled compilers are going to be used.

[markd@…]

Has 1.5.22 fixed the problem?

[markd@…]

So it sounds like using Apple's libtool with Apple gcc and possibly MacPorts libtool with MacPorts compilers is best.