Opened 2 years ago

Last modified 11 days ago

#69944 assigned defect

zstd @1.5.6: does not respect macos setting on build

Reported by: lukaso (Lukas Oberhuber) Owned by: MarcusCalhoun
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: zstd

Description

Even after setting this, the build still leaves zstd build for the MacOS version it is running on:

  echo 'macosx_deployment_target 10.13' | tee -a ${PREFIX}/etc/macports/macports.conf
  echo 'macosx_sdk_version 10.13' | tee -a ${PREFIX}/etc/macports/macports.conf

From otool -l

Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 13.0
      sdk 13.3
   ntools 1
     tool 3
  version 857.1

Change History (13)

comment:1 Changed 2 years ago by lukaso (Lukas Oberhuber)

It looks like this bug was introduced upstream in v1.5.6

comment:2 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: set to MarcusCalhoun
Status: newassigned
Summary: zstd @ 1.5.6: does not respect macos setting on buildzstd @1.5.6: does not respect macos setting on build

comment:3 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)

Do you check each library manually or is there an easy way to audit all of the libraries that your program depends on to find the ones that have this problem?

comment:4 Changed 2 years ago by lukaso (Lukas Oberhuber)

I’ve written a program to check it (or should I say, chat-gpt wrote me a program to check it.) Happy to upload if it would be helpful.

But in this instance it came via a bug report as I’d not incorporated the script into the CI system.

comment:5 Changed 2 years ago by lukaso (Lukas Oberhuber)

Similar to #69947

Last edited 2 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:6 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)

I was just curious for my own purposes whether you had to parse the otool -l output or if there was a better API for getting just the interesting values, and how you were collecting the list of libraries that you needed to check.

comment:7 Changed 20 months ago by lukaso (Lukas Oberhuber)

comment:8 Changed 20 months ago by lukaso (Lukas Oberhuber)

whether you had to parse the otool -l output or if there was a better API

I parse otool -l to answer your actual question.

how you were collecting the list of libraries that you needed to check

I use a bunch of packaging scripts, which, to make a long story short, follow all the library dependencies from GIMP on down and copy them into the relevant directories, while fixing up @rpaths and doing a bunch of other admin. I then run this script on all libraries that have been copied in and which will eventually be packaged into GIMP.app.

comment:9 Changed 20 months ago by lukaso (Lukas Oberhuber)

here's the upstream issue (should have posted as well): https://github.com/facebook/zstd/issues/4038

comment:10 Changed 19 months ago by lukaso (Lukas Oberhuber)

Fix submitted and approved (but not merged): https://github.com/facebook/zstd/pull/4191

comment:11 Changed 19 months ago by lukaso (Lukas Oberhuber)

From zstd. Closed #4038(https://github.com/facebook/zstd/issues/4038) as completed via [d0fe334](https://github.com/facebook/zstd/commit/d0fe334c8552edb764b853854037697c6710fa64).

I think we'll have to wait on 1.5.8 however to get the fix.

comment:12 Changed 11 days ago by lukaso (Lukas Oberhuber)

comment:13 Changed 11 days ago by lukaso (Lukas Oberhuber)

Ticket should be closed.

Note: See TracTickets for help on using tickets.