Cannot create bottle for tcl-tk with a newer brew than 3.3.11 #12832
Comments
This comment was marked as resolved.
This comment was marked as resolved.
request-info
bot
added
the
needs response
|
What's the output of ? |
|
I'm going to guess the install name of When the install name is just a basename |
|
I'm confused about when this problem was introduced though, even supposing I'm correct. Any chance you could do a |
|
|
Well, close enough. Still just a basename: |
|
@MikeMcQuaid I think this is a bug in |
This comment was marked as resolved.
This comment was marked as resolved.
|
Finally finished with the git bisect. 568bc94 is the first bad commit Library/Homebrew/extend/os/mac/keg_relocate.rb | 10 +--------- |
|
Thanks. That's the only closely related change recently, so it makes sense. On the other hand, I don't see how that affects what currently looks like unrelated code... |
|
Can you show the output of |
|
|
I can reproduce this, but I'm still not quite sure why it's happening. Just to double-check: what is the output of |
|
FWIW, I'm seeing the same issue when bottling |
|
My last theory was that this is a regression in The problem is that For some reason, The right fix is probably to make sure But that still leaves open the question of how this even got broken in the first place. You could try reverting my commit from the |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@carlocab, I can confirm that grpc.build-bottle.v1.log and after reverting: grpc.build-bottle.v2.log Note that pre-revert, even though the log says: the change doesn't seem to be applied: |
|
One thing I am confused about: 568bc94 only affects the rewriting of |
|
If I'm reading the commit correctly, it replaces an open-edit-write sequence on a dylib filename ( |
|
I still don't see how that's related to our reading of dylib IDs (and subsequent re-reading and replacing) from the cache, though. |
|
I'm not sure either, and I'm definitely not familiar with the codebase, but since that's the only effective logic difference, that suggests a failure to commit existing changes somewhere, or overwritten changes. Some years back, I wrote some code that ending up doing something like the following:
Needless to say, the changes in A disappeared without a trace. |
|
Ah, yes, I see. Here's what's happening:
Thus our changes from 2 disappear. Do you mind testing this patch? I'll open a PR for it shortly. diff --git a/Library/Homebrew/os/mac/keg.rb b/Library/Homebrew/os/mac/keg.rb
index ef4395bb6..ead4ad6d7 100644
--- a/Library/Homebrew/os/mac/keg.rb
+++ b/Library/Homebrew/os/mac/keg.rb
@@ -7,7 +7,7 @@ class Keg
@require_relocation = true
odebug "Changing dylib ID of #{file}\n from #{file.dylib_id}\n to #{id}"
- MachO::Tools.change_dylib_id(file, id, strict: false)
+ file.change_dylib_id(id, strict: false)
apply_ad_hoc_signature(file)
rescue MachO::MachOError
onoe <<~EOS
@@ -23,7 +23,7 @@ class Keg
@require_relocation = true
odebug "Changing install name in #{file}\n from #{old}\n to #{new}"
- MachO::Tools.change_install_name(file, old, new, strict: false)
+ file.change_install_name(old, new, strict: false)
apply_ad_hoc_signature(file)
rescue MachO::MachOError
onoe <<~EOS
@@ -39,7 +39,7 @@ class Keg
@require_relocation = true
odebug "Changing rpath in #{file}\n from #{old}\n to #{new}"
- MachO::Tools.change_rpath(file, old, new, strict: false)
+ file.change_rpath(old, new, strict: false)
apply_ad_hoc_signature(file)
rescue MachO::MachOError
onoe <<~EOS
diff --git a/Library/Homebrew/os/mac/mach.rb b/Library/Homebrew/os/mac/mach.rb
index bd636ffba..abadcf8fd 100644
--- a/Library/Homebrew/os/mac/mach.rb
+++ b/Library/Homebrew/os/mac/mach.rb
@@ -64,6 +64,21 @@ module MachOShim
macho.write!
end
+ def change_rpath(old, new, **options)
+ macho.change_rpath(old, new, options)
+ macho.write!
+ end
+
+ def change_dylib_id(id, **options)
+ macho.change_dylib_id(id, options)
+ macho.write!
+ end
+
+ def change_install_name(old, new, **options)
+ macho.change_install_name(old, new, options)
+ macho.write!
+ end
+
def dynamically_linked_libraries(except: :none)
lcs = macho.dylib_load_commands.reject { |lc| lc.type == except } |
We were rewriting dylib IDs and install names using `MachO::Tools`, which doesn't update the state of the file in memory. This leads to those changes being undone when we call `change_rpath`. We fix this by making sure the state of the file in memory always matches the state of file on disk. Closes Homebrew#12832.
|
This was surprisingly subtle. (Though maybe I should know better than to be surprised.) Thanks for the help figuring this out, @gromgit, and thanks for helping track down the offending commit, @imresteiner. Should be closed by #12864. |
We were rewriting dylib IDs and install names using `MachO::Tools`, which doesn't update the state of the file in memory. This leads to those changes being undone when we call `delete_rpath`. We fix this by making sure the state of the file in memory always matches the state of file on disk. Closes Homebrew#12832.
brew configoutputbrew doctoroutputVerification
brew updateand am still able to reproduce my issue.brew doctorand that did not fix my problem.What were you trying to do (and why)?
I would like to update the formulas we are using to build our product. To release the binaries another git branch was created which is reseted to the homebrew-core repo's master.
What happened (include all command output)?
brew bottle --json tcl-tkcommand failed.output:
After a short investigation it seems an empty id is generated for the lib at Library/Homebrew/extend/os/mac/keg_relocate.rb:25
==> FILE: /opt/bb-brew/Cellar/tcl-tk/8.6.12_1/lib/tcltls1.7.22/tcltls.dylib
==> FILE.DYLIB_ID shared-tcltls.dylib
==> ID:
With version 3.3.11 brew can build the bottle successfully. With a newer version I could reproduce the issue.
What did you expect to happen?
The json config is generated to create a bottle afterwards.
Step-by-step reproduction instructions (by running
brewcommands)The text was updated successfully, but these errors were encountered: