Ticket #23684 (closed defect: fixed)
libtool @2.2.6b installs sometimes lack dylibs
| Reported by: | gnwiii@… | Owned by: | ryandesign@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.8.2 |
| Keywords: | Cc: | dports@…, nilstec_inc@…, gabriele.svelto@…, vortexfive@…, ted@…, rob.patro@…, christophe@…, david.w.watson@…, michael.secules@…, amruta.ahuja@…, zouhu0628@…, gsiisg@…, jelkink@…, f.calboli@…, kai.vanes@… | |
| Port: | libtool |
Description
Have 6 OSX 10.5.8 machines with essentially the same macports 1.8.2 configuration and packages. On some machines we have:
/opt/local/lib/libltdl.7.dylib
others only the static libraries. Our programs compiled on the machines with the .dylib won't run on the others.
For the machines without the dylib, libtool was installed in Nov. (so probably an older version of macports). The ones with the .dylib were installed in Jan. I did:
port uninstall -f libtool; port install libtool
on two of the machines that did not have .dylib but only one of them ended up with the .dylib! The problem appears to be that some users have symbolic links for /opt/local/bin/gfortran. If such links are present, you don't get the dylib.
I have attached the output from "port -d install libtool" from runs with (nodylib.log) and without (libtool.log) the gfortran symlinks
Note that the system that fails to install the .dylib hasL
nodylib.log:libtool.m4: error: problem compiling FC test program
Attachments
Change History
Changed 3 years ago by gnwiii@…
- Attachment libtool.log added
Changed 3 years ago by gnwiii@…
- Attachment nodylib.log added
port -d install libtool that does not install .dylib
comment:1 Changed 3 years ago by macsforever2000@…
- Owner changed from macports-tickets@… to boeyms@…
- Keywords libtool dylib removed
- Port set to libtool
comment:3 Changed 3 years ago by jmr@…
It doesn't look like this is about libtool failing to build dylibs for other software, but rather about libltdl.dylib being omitted when building libtool itself.
comment:4 Changed 3 years ago by dports@…
I fail at reading comprehension -- I totally missed that libltdl is part of libtool itself rather than some other random dylib.
Still wonder if it could be related, though, since the problem there appears to be that libtool is not building static libraries, and reinstalling libtool fixed it for at least one person.
comment:5 Changed 3 years ago by dports@…
Oh, also, per comment:ticket:25417:11, that also appears to be related to having gfortran installed.
comment:6 Changed 2 years ago by jmr@…
- Status changed from new to closed
- Resolution set to fixed
I can't reproduce this problem with libtool 2.4.
comment:7 Changed 19 months ago by ryandesign@…
- Cc nilstec_inc@…, gabriele.svelto@…, vortexfive@…, ted@…, rob.patro@…, christophe@…, david.w.watson@…, michael.secules@…, amruta.ahuja@…, zouhu0628@…, gsiisg@…, jelkink@…, f.calboli@…, kai.vanes@… added
- Status changed from closed to reopened
- Resolution fixed deleted
comment:8 Changed 19 months ago by ryandesign@…
- Status changed from reopened to new
- Owner changed from boeyms@… to ryandesign@…
I brought the issue up with the developers of libtool on their mailing list, and Peter O'Gorman's reply was that this is a bug in libtool's build. libtool's build looks for a fortran compiler, and when it finds one, but it is broken, it takes note of the fact that the fortran compiler cannot build shared libraries, but this mistakenly overrides the earlier detection that the C and C++ compilers are able to (and should) create shared libraries. Peter provided a solution to prevent libtool from attempting to locate a fortran compiler, which in MacPorts we never want libtool to be doing anyway.
port -d install libtool that installs .dylib