Opened 4 weeks ago
Last modified 10 days ago
#69643 assigned defect
gstreamer1 @1.24.1_0+universal: linking of temporary binary failed
Reported by: | thetrial (alabay) | Owned by: | barracuda156 |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.1 |
Keywords: | legacy-os, sierra | Cc: | mascguy (Christopher Nielsen), jpenney (Jason Penney) |
Port: | gstreamer1 |
Description
Something is not working, and I don’t know what. I’ll attach the logfile.
Attachments (2)
Change History (11)
Changed 4 weeks ago by thetrial (alabay)
comment:1 Changed 4 weeks ago by ryandesign (Ryan Carsten Schmidt)
Owner: | set to barracuda156 |
---|---|
Status: | new → assigned |
comment:2 Changed 4 weeks ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:3 follow-up: 4 Changed 4 weeks ago by Gcenx
Weirdly I don’t remember having issues with gobject-introspection when I’d originally started to carry an updated copy of GStreamer1 ports but I did move to using muniversal-1.1. I’ve since removed gobject-introspection from the custom gstreamer based package I’m maintaining.
comment:4 Changed 4 weeks ago by barracuda156
Replying to Gcenx:
Weirdly I don’t remember having issues with gobject-introspection when I’d originally started to carry an updated copy of GStreamer1 ports but I did move to using muniversal-1.1. I’ve since removed gobject-introspection from the custom gstreamer based package I’m maintaining.
I have nothing to test universal built at the moment. Does switching to muniversal 1.0
fix the problem for the current version?
comment:5 follow-up: 7 Changed 4 weeks ago by christophecvr (christophecvr)
Hello I we are running in a lot of more problems just because gstreamer1.24.1 is not build like it should for example on macbookpro mid 2010 using intel 64 arch macos-10.13.6 (High Sierra) xcode 10.1 . nvidia graphics (means opengl support is a must). The base x11 is indeed only for x86_64 arch.The winsys is multiver or even i386 so x11 and winsys with opengl is not possible it will break on issues like x86_64 bla bla bla not found. x11 is a must , gl support is a must. The base gl support has been moved from gst-plugins-bad to gst-plugins-base . Here just a temporary show how we can work further on . Off course this is for intel 64 nvidia graphics and a base core which is x86_64 (yes on high sierra there is still multiver support but mostly it bugs with x11 since that is build for x86_64 only and that is ok and right.) See the patch I did to the macports-ports with that path i'm able to build gstreamer1 with opengl and x11 support that is required.
https://github.com/christophecvr/macports-ports/commit/cb7c24829824fdd418f48e5a9d92279619b6391e
I will also add a debug of build of terminal.
Changed 4 weeks ago by christophecvr (christophecvr)
Attachment: | gstreamer1-gst-plugins-base-1.24.1-build-term-out.txt added |
---|
Succesfull Build of gstreamer1-gst-plugins-base with x11 and gl support no winsys.
comment:6 Changed 3 weeks ago by jpenney (Jason Penney)
Cc: | jpenney added |
---|
comment:7 Changed 3 weeks ago by barracuda156
Replying to christophecvr:
Hello I we are running in a lot of more problems just because gstreamer1.24.1 is not build like it should for example on macbookpro mid 2010 using intel 64 arch macos-10.13.6 (High Sierra) xcode 10.1 . nvidia graphics (means opengl support is a must). The base x11 is indeed only for x86_64 arch.The winsys is multiver or even i386 so x11 and winsys with opengl is not possible it will break on issues like x86_64 bla bla bla not found. x11 is a must , gl support is a must. The base gl support has been moved from gst-plugins-bad to gst-plugins-base . Here just a temporary show how we can work further on . Off course this is for intel 64 nvidia graphics and a base core which is x86_64 (yes on high sierra there is still multiver support but mostly it bugs with x11 since that is build for x86_64 only and that is ok and right.) See the patch I did to the macports-ports with that path i'm able to build gstreamer1 with opengl and x11 support that is required.
https://github.com/christophecvr/macports-ports/commit/cb7c24829824fdd418f48e5a9d92279619b6391e
I will also add a debug of build of terminal.
- If you want to tweak compiler choice for a given port, do it in a portfile. It is not acceptable or even useful to do it generally (unless a compiler is just broken, which is not the case for clang-15/16). By the way, if Apple clang cannot build this, it should be raised to upstream, I guess, that looks like a bug.
- I find your exposition confusing, sorry. The port should support all archs (which include arm64 and ppc/ppc64), so if something is for intel 64 Nvidia, it cannot be a general setting. If older systems and powerpc need special settings, those can be made conditional. Same goes for the latest macOS versions, if those require special settings.
- If some configure args _really_ have to be just removed, a comment it a portfile will be helpful, otherwise someone may add them back, or think it was an accidental removal, etc.
comment:8 Changed 2 weeks ago by thetrial (alabay)
By the way … the and not
command switch seems not to work [always|anymore].
sudo port upgrade outdated and not \( gstreamer1 \)
does not prevent from trying to build gstreamer1 … and that breaks MacPorts’ upgrade more or less completely. Yesterday I had a new problem I cannot reproduce today because of upgrading (again) not reaching this point anymore (glib2 related).
comment:9 Changed 10 days ago by thetrial (alabay)
Is there any prospect of getting the problem under control?
I see this in the log which may not be related to the problem you're seeing but definitely looks wrong:
This block of code, whatever it is, is intended for macOS versions earlier than 10.5, but because
MAC_OS_X_VERSION_MIN_REQUIRED
is not defined and evaluates to0
, it is taking effect for all versions of macOS. This file needs to#include <AvailabilityMacros.h>
to get the definition ofMAC_OS_X_VERSION_MIN_REQUIRED
.As for the real problem in the log, I see you're building universal and that this port uses the muniversal portgroup so it builds the different architectures separately. I'm seeing a successful build of the x86_64 part but the i386 part fails because the right arch flags have not been used for everything, specifically not when building the temporary binary used for gobject introspection:
Since there were no
-arch
flags here, it built for the default arch x86_64 and was unable to link with the i386 flavor of the library that was just built:As a result, all of the symbols that that library should provide are undefined:
This is exactly the problem that the gobject_introspection 1.0 portgroup was designed to solve. The port used to include that portgroup until yesterday when the port was updated to a new version and its build system was switched to meson. The gobject_introspection 1.0 portgroup was designed for the autotools build system and I don't know if it works with the meson build system. If not, hopefully it can be enhanced to do so. I've seen many ports remove the inclusion of the gobject_introspection 1.0 portgroup and instead copy/paste code into the Portfile to handle the situation, a practice I would really love to see the end of. That's why we have portgroups: to consolidate common logic in one place.