Created attachment 238432 [details] portmaster log file Building gstreamer1-1.20.4 on 13.1-STABLE fails at this point: ld: error: undefined symbol: gst_aggregator_start_time_selection_get_type >>> referenced by GstBase-1.0.c >>> /usr/ports/multimedia/gstreamer1/work/gstreamer-1.20.4/_build/tmp-introspect1mf1iuvy/GstBase-1.0.o:(GI_GET_TYPE_FUNCS_) cc: error: linker command failed with exit code 1 (use -v to see invocation) as indicated in the attached log file.
Does it also fail in a proper clean build environment (i.e. poudriere jail)?
Me too, on updating from gstreamer1-1.16.2. However, after pkg remove gstreamer1-1.16.2, it was built successfully.
I don't use poudriere, so I don't know if it fails there as well. Probably not or someone would have found out before commiting the updated port. The trick of removing the installed version worked for me. This was needed for gstreamer1-plugins as well, but not for gstreamer1-plugins-bad or gstreamer1-plugins-gl. It looks like the build process, when not insulated, somehow uses / includes / links something that is in the installed version instead of the version from its work directory.
The requirement of removing the old version when building on a system with the old version installed is mentioned in UPDATING. Is there any information missing in UPDATING?
I had not paid attention to the entry in UPDATING, I'm sorry for the trouble. As far as I'm concerned, you can close the report.
OK, thanks! "Works as intended" is probably not the perfect status update, but the closest one...
Created attachment 243619 [details] Remove the first -L${PREFIX}/lib from link-lines This remains a problem today with 1.22.5 -- the issue should've been reported upstream, when first encountered. Chances are, it would've been fixed by now. That UPDATING-entry was an admission of defeat: "We know of the problem, we cannot fix it" :-( The root cause is that the linker line lists the library directories thus: -L${WRKSRC}/_build/gst -L${LOCALBASE}/lib -L${WRKSRC}/_build/libs/gst/base -L${WRKSRC}/_build/gst -L${LOCALBASE}/lib -L${LOCALBASE}/lib The ${LOCALBASE}/lib/libgstbase-1.0.so.0.1602.0, which I currently have installed, does NOT have this function defined, but it is picked up first, because ${LOCALBASE}/lib is listed before the ${WRKSRC}/_build/libs/gst/base. Notably, this is not a problem for the compile-stage -- the -I arguments list ${LOCALBASE}/include last. But -L ones are wrong... The proposed patch offers one way to solve this -- a hackish way, because I don't know, how meson/ninja are supposed to work. There should be a better way -- and the port's maintainer should have the upstream figure it out. The patch also fixes the spaces in a few spots -- replacing them with tabs. Feel free to ignore those hunks, concentrating on just the new post-configure target.
Created attachment 243621 [details] Remove the first -L${PREFIX}/lib from link-lines Add (almost) the same trick to gstreamer1-plugs/Makefile.common
Tested the patch on one more machine -- worked nicely. Reopening for the committer...
(In reply to Mikhail T. from comment #7) However, it may be that simply doing the following will solve the problem. But, it has not even been tested because the environment in which the old version was installed is gone. --- meson.build.orig 2023-07-20 14:22:48 UTC +++ meson.build @@ -634,8 +634,8 @@ endif static_build = get_option('default_library') == 'static' gst_libraries = [] -subdir('gst') subdir('libs') +subdir('gst') subdir('plugins') subdir('tools') subdir('tests')
(In reply to Tatsuki Makino from comment #10) I thought, but it wasn't that easy to solve 🤣 cmake specifies all libraries with full paths, why is meson such a pain in the ass again....
(In reply to Tatsuki Makino from comment #10) Thank you. Unlike my hack, this looks like something, that can be submitted upstream... > But, it has not even been tested because the environment in which > the old version was installed is gone You don't need the old version installed in order to test. You can simply confirm, that the /usr/local/lib is last on the list of library paths -- the way /usr/local/include is the last on the list of include-paths.