emqx: upgrade to 5.1.4 and fix linkage issue

[id]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[id]

This library should be copied verbatim from erlang@25 install, but something overwrites load command adding 2 extra ../../ in the process.

$ otool -l $(brew --prefix emqx)/lib/crypto-5.1.4/priv/lib/crypto.so
Load command 10
          cmd LC_LOAD_DYLIB
      cmdsize 104
         name @loader_path/../../../../../../../../../opt/openssl@3/lib/libcrypto.3.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 3.0.0
compatibility version 3.0.0

[carlocab]

This library should be copied verbatim from erlang@25 install, but something overwrites load command adding 2 extra ../../ in the process.

Well, not quite. The issue is that crypto.so lives in

lib/erlang/lib/crypto-5.1.4/priv/lib

while emqx copies the crypto.so from erlang@25 into

lib/crypto-5.1.4/priv/lib

which is two directories shorter (and explains the extra ../../).

You can't just relocate binaries arbitrarily and expect them to keep working.

[id]

while emqx copies the crypto.so from erlang@25 into

the error have been occurring before this patch.

[id]

@carlocab erlang's crypto.so uses absolute path to load libcrypto.3.dylib, while in emqx it somehow got changed to relative.

[carlocab]

erlang's crypto.so uses absolute path to load libcrypto.3.dylib

Not in CI, it doesn't.

❯ otool -L "$(brew --prefix erlang@25)/lib/erlang/lib/crypto-5.1.4/priv/lib/crypto.so"
/usr/local/opt/erlang@25/lib/erlang/lib/crypto-5.1.4/priv/lib/crypto.so:
        @loader_path/../../../../../../../../../opt/openssl@3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)

[id]

Interesting, for me it was showing this:

/opt/homebrew//Cellar/erlang@25/25.3.2.5/lib/erlang/lib/crypto-5.1.4/priv/lib/crypto.so:
        /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)

[id]

different behaviour on arm/intel?

[id]

@carlocab was there some recent change in brew which started overwriting load path to dynamic libraries to relative?

[id]

Ok, solved it.
Please let me know guys if you like this solution or we need to do something else.

[carlocab]

Thanks, one suggestion.

Also, I noticed that the build vendors a whole lot of things that Homebrew provides (e.g. lz4, rocksdb, etc.). We should change that given https://docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae.

[id]

I noticed that the build vendors a whole lot of things that Homebrew provides (e.g. lz4, rocksdb, etc.). We should change that given docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae.

Thanks, brought this up with the team. It's not a trivial issue to solve, but I agree it's reasonable to expect from a library to make use of components already present in the system, if possible.

[carlocab]

LGTM; thanks!

[github-actions]

⛔ It looks like @BrewTestBot cannot push to your PR branch. For future pull requests, please allow maintainers to edit your PR to simplify the merge process.

[github-actions]

🤖 An automated task has requested creation of a replacement PR.

Replacement PR dispatched

[github-actions]

⚠️ Replacement PR creation failed. CC @carlocab

[id]

Apparently I cannot allow maintainers to edit PR because fork is owned by organization: https://github.com/orgs/community/discussions/5634.

Should I fork homebrew-core into my personal acc and create another PR?

[id]

--> #140246