Changes between Initial Version and Version 1 of Ticket #69806, comment 7


Ignore:
Timestamp:
Apr 30, 2024, 12:33:35 AM (7 months ago)
Author:
ryandesign (Ryan Carsten Schmidt)
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #69806, comment 7

    initial v1  
    66> }}}
    77
    8 /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/build/tools/g-ir-compiler wants to use @loader_path/libgirepository-1.0.1.dylib and it is not found. `@loader_path` expands to the path of the directory of whatever is doing the loading, in this case g-ir-compiler, so the library it is looking for is /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/build/tools/libgirepository-1.0.1.dylib. Does that library exist? If not, does the library exist at a different path in the work directory? If it's at a different path, that shows us that the install name of the library is wrong. Which we already know: we don't install libraries with `@loader_path` in their install names, so perhaps the build knowingly builds things with wrong install names and fixes them up later with `install_name_tool`. Of course, if the build is going to run programs like `g-ir-compiler` during the build that link with just-built libraries, the install names either have to be correct for the locations in the build tree or typically `DYLD_LIBRARY_PATH` just has to be set to the directory containing the libraries. I see that the build phase sets `DYLD_LIBRARY_PATH='/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/build/girepository'` and it's in a `platform darwin 8` block in the Portfile with a comment that this is only done because 10.4 doesn't support rpath which the build would presumably use on 10.5. Is the library in that path? If not, then this Tiger-specific code in the Portfile needs adjusting.
     8/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/build/tools/g-ir-compiler wants to use @loader_path/libgirepository-1.0.1.dylib and it is not found. `@loader_path` expands to the path of the directory of whatever is doing the loading, in this case g-ir-compiler, so the library it is looking for is /opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/build/tools/libgirepository-1.0.1.dylib. Does that library exist? If not, does the library exist at a different path in the work directory? If it's at a different path, that shows us that the install name of the library is wrong. Which we already know: we don't install libraries with `@loader_path` in their install names, so perhaps the build knowingly builds things with wrong install names and fixes them up later with `install_name_tool`. Of course, if the build is going to run programs like `g-ir-compiler` during the build that link with just-built libraries, the install names either have to be correct for the locations in the build tree or typically `DYLD_LIBRARY_PATH` just has to be set to the directory containing the libraries. I see that the build phase sets `DYLD_LIBRARY_PATH='/opt/local/var/macports/build/_opt_local_var_macports_sources_nue.de.rsync.macports.org_macports_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/build/girepository'` and it's in a `platform darwin 8` block in the Portfile with a comment that this is only done because 10.4 doesn't support `@rpath` which the build would presumably use on 10.5. Is the library in that path? If not, then this Tiger-specific code in the Portfile needs adjusting.