Created attachment 501524 [details] build.log emerge --update -1 dev-perl/Text-BibTeX fails with "invalid install_name found" error (updating from 0.790.0) The culprits seem to be: $EPREFIX/usr/bin/biblex $EPREFIX/usr/bin/bibparse $EPREFIX/usr/bin/dumpnames $EPREFIX/usr/lib/libbtparse.dylib (see lines 191 -- 194 in build.log) The other set of suspicious messages are in lines 95 -- 110: error: install_name_tool: can't open input file: ./blib/usrlib/libbtparse.dylib for writing (Permission denied) error: install_name_tool: can't lseek to offset: 0 in file: ./blib/usrlib/libbtparse.dylib for writing (Bad file descriptor) error: install_name_tool: can't write new headers in file: ./blib/usrlib/libbtparse.dylib (Bad file descriptor) error: install_name_tool: can't close written on input file: ./blib/usrlib/libbtparse.dylib (Bad file descriptor) error: install_name_tool: can't open input file: ./blib/bin/biblex for writing (Permission denied) error: install_name_tool: can't lseek to offset: 0 in file: ./blib/bin/biblex for writing (Bad file descriptor) error: install_name_tool: can't write new headers in file: ./blib/bin/biblex (Bad file descriptor) error: install_name_tool: can't close written on input file: ./blib/bin/biblex (Bad file descriptor) error: install_name_tool: can't open input file: ./blib/bin/bibparse for writing (Permission denied) error: install_name_tool: can't lseek to offset: 0 in file: ./blib/bin/bibparse for writing (Bad file descriptor) error: install_name_tool: can't write new headers in file: ./blib/bin/bibparse (Bad file descriptor) error: install_name_tool: can't close written on input file: ./blib/bin/bibparse (Bad file descriptor) error: install_name_tool: can't open input file: ./blib/bin/dumpnames for writing (Permission denied) error: install_name_tool: can't lseek to offset: 0 in file: ./blib/bin/dumpnames for writing (Bad file descriptor) error: install_name_tool: can't write new headers in file: ./blib/bin/dumpnames (Bad file descriptor) error: install_name_tool: can't close written on input file: ./blib/bin/dumpnames (Bad file descriptor)
Created attachment 501526 [details] Output of emerge --info '=dev-perl/Text-BibTeX-0.800.0::gentoo_prefix'
Created attachment 501528 [details] emerge -pqv '=dev-perl/Text-BibTeX-0.800.0::gentoo_prefix'
Created attachment 501530 [details] emerge --pretend --update -1 dev-perl/Text-BibTeX
Created attachment 501648 [details, diff] Workaround This patch does "chmod u+w" to those files which could not be processed by install_name_tool in the original emerge attempt. It apparently works-for-me, so I conclude that being non-writable was indeed the problem. That said, I don't have a deep understanding of perl libraries or emerge, which means: 1) If there was a deep reason for the files to be non-writable, this patch might break something subtle. (The finally installed files are non-writable even with this patch) 2) There could exist a more elegant/appropriate solution.
Thanks for your analysis and patch! It is indeed weird that the files are read-only. Most (if not all) libs I have are 755, so it certainly seems weird to install with a different mode. Just to check do you set umask?
the problem is the use of copy_if_modified: copy_if_modified(%parameters) [version 0.19] Takes the file in the from parameter and copies it to the file in the to parameter, or the directory in the to_dir parameter, if the file has changed since it was last copied (or if it doesn't exist in the new location). By default the entire directory structure of from will be copied into to_dir; an optional flatten parameter will copy into to_dir without doing so. Returns the path to the destination file, or undef if nothing needed to be copied. Any directories that need to be created in order to perform the copying will be automatically created. The destination file is set to read-only. If the source file has the executable bit set, then the destination file will be made executable. So it seems backwards fixing is the only way. @perl: what do you think?
(In reply to Fabian Groffen from comment #6) > So it seems backwards fixing is the only way. > @perl: what do you think? Not 100% sure. However, I do know it is standard that everything installed by the Perl Toolchain does get marked read-only during install. === $ cpanm --look Module::Build --> Working on Module::Build Fetching http://www.cpan.org/authors/id/L/LE/LEONT/Module-Build-0.4224.tar.gz ... OK Entering /home/kent/.cpanm/work/1519784274.10727/Module-Build-0.4224 with /bin/bash $ perl ./Build.PL Created MYMETA.yml and MYMETA.json Creating new 'Build' script for 'Module-Build' version '0.4224' $ ./Build Building Module-Build $ find blib/ -type f -ls | grep ' [-]rw-' 15080371 8 -rw-r--r-- 1 kent kent 6842 Feb 28 15:18 blib/lib/Module/Build/ConfigData.pm $ find blib/ -type f -ls | grep ' [-]r--' 15077593 36 -r--r--r-- 1 kent kent 35680 Feb 28 15:18 blib/lib/Module/Build.pm 15080369 12 -r--r--r-- 1 kent kent 11004 Feb 28 15:18 blib/lib/Module/Build/Authoring.pod 15080364 4 -r--r--r-- 1 kent kent 1114 Feb 28 15:18 blib/lib/Module/Build/Platform/cygwin.pm 15080365 4 -r--r--r-- 1 kent kent 826 Feb 28 15:18 blib/lib/Module/Build/Platform/darwin.pm 15080355 4 -r--r--r-- 1 kent kent 1777 Feb 28 15:18 blib/lib/Module/Build/Platform/Unix.pm 15080354 4 -r--r--r-- 1 kent kent 3561 Feb 28 15:18 blib/lib/Module/Build/Platform/MacOS.pm 15080356 12 -r--r--r-- 1 kent kent 12244 Feb 28 15:18 blib/lib/Module/Build/Platform/VMS.pm 15080359 4 -r--r--r-- 1 kent kent 536 Feb 28 15:18 blib/lib/Module/Build/Platform/VOS.pm 15080366 4 -r--r--r-- 1 kent kent 894 Feb 28 15:18 blib/lib/Module/Build/Platform/os2.pm 15080363 4 -r--r--r-- 1 kent kent 810 Feb 28 15:18 blib/lib/Module/Build/Platform/aix.pm 15080353 4 -r--r--r-- 1 kent kent 544 Feb 28 15:18 blib/lib/Module/Build/Platform/Default.pm 15080360 8 -r--r--r-- 1 kent kent 7934 Feb 28 15:18 blib/lib/Module/Build/Platform/Windows.pm 15080343 4 -r--r--r-- 1 kent kent 1102 Feb 28 15:18 blib/lib/Module/Build/Config.pm 15080367 4 -r--r--r-- 1 kent kent 1305 Feb 28 15:18 blib/lib/Module/Build/PodParser.pm 15080344 20 -r--r--r-- 1 kent kent 17337 Feb 28 15:18 blib/lib/Module/Build/Cookbook.pm 15080350 8 -r--r--r-- 1 kent kent 4538 Feb 28 15:18 blib/lib/Module/Build/PPMMaker.pm 15080345 4 -r--r--r-- 1 kent kent 454 Feb 28 15:18 blib/lib/Module/Build/Dumper.pm 15080368 68 -r--r--r-- 1 kent kent 68697 Feb 28 15:18 blib/lib/Module/Build/API.pod 15079729 20 -r--r--r-- 1 kent kent 18538 Feb 28 15:18 blib/lib/Module/Build/Compat.pm 15077594 164 -r--r--r-- 1 kent kent 165204 Feb 28 15:18 blib/lib/Module/Build/Base.pm 15080370 8 -r--r--r-- 1 kent kent 5108 Feb 28 15:18 blib/lib/Module/Build/Bundling.pod 15080349 12 -r--r--r-- 1 kent kent 8312 Feb 28 15:18 blib/lib/Module/Build/Notes.pm === That this package is the only one tripping over that makes me suspicious. copy_if_modified is itself, also in widespread use and employed in a seemingly hot path in Module::Build itself: https://grep.metacpan.org/search?qci=&q=%28process_files_by_extension|copy_if_modified%29&qft=&qd=Module-Build&f=lib%2FModule%2FBuild%2FBase.pm So it seems something is awry in a location other than those we've looked at so far, because based on what the nature of this issue is: All packages that employ Module::Build should be broken on darwin prefix, and maybe even on native darwin... and that just can't be right.
support for this package has disappeared
