Created attachment 206360 [details]
poudriere testport log for blender-2.79b_14 (gzipped)
The build of graphics/blender fails during compilation on amd64 11.3-RELEASE-p2.
/usr/local/lib/libflite_cmu_us_kal.so.1: undefined reference to `cmu_postlex'
/usr/local/lib/libflite_cmu_us_awb.so.1: undefined reference to `usenglish_init'
/usr/local/lib/libflite_cmu_us_awb.so.1: undefined reference to `cmu_lex_init'
c++: error: linker command failed with exit code 1
I have attached the poudriere testport log with ccache disabled. You will see I use non-default options, though also experience the same build error with default graphics/blender options.
Version 2.79b_13 previously built successfully. Many thanks in advance for investigating.
A similar error happens here with ffmpeg bug #239567. Fixed on 1. August 2019.
Created attachment 206362 [details]
poudriere testport log for patched Makefile
Created attachment 206363 [details]
Proposed Makefile patch
Many thanks for spotting that, Walter.
I have attached a proposed patch for the Makefile (to set LDFLAGS= -fuse-ld=lld) and the poudriere testport log showing the build completing successfully.
Created attachment 206368 [details]
Proposed Makefile patch v2
Having done some reading (also pointed out in bug #239567, comment #5) around the transition to the LLVM linker and discovering that:
(a) It may already be the default linker (see WITH_LLD_IS_LD in src.conf(5)) and (b) The LLVM linker is not available on all architectures,
I propose to wrap the LDFLAGS in an if statement as per the workaround suggested in bug #239567, comment #6. Note this doesn't guarantee that linking will work correctly but does at least mean that architectures without the LLVM linker will not definitely be broken.
Updated proposed patch and poudriere testport log attached.
Created attachment 206369 [details]
poudriere testport log for patched Makefile v2
If this is needed, it should be added to bug #239589 where this port is being updated to 2.80
Does the 2.80 version make a difference?
(In reply to Shane from comment #7)
Shane, thanks for your reply. Unfortunately I've not been able to successfully apply your patch from bug 239589. Having first tried to apply the patch to the latest revision of the ports tree I saw the patch is for port revision 13, not 14. I then attempted to apply it to revision 508215 of the ports tree (that is, the commit just prior to the one for graphics/blender revision 14).
The patch check succeeds for all files except the Makefile. Have I made an error in my approach (below)?
% svnlite checkout https://svn.FreeBSD.org/ports/head@508215 ./blendertesting
% cd blendertesting
% patch -Cu < ~/blender28.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
|diff -Nru graphics/blender.orig/Makefile graphics/blender/Makefile
|--- graphics/blender.orig/Makefile 2019-08-02 13:52:14.343159000 +0930
|+++ graphics/blender/Makefile 2019-08-02 13:51:38.830466000 +0930
Patching file Makefile using Plan A...
Hunk #1 failed at 2.
Hunk #2 failed at 24.
Hunk #3 failed at 74.
Hunk #4 failed at 92.
Hunk #5 failed at 125.
Hunk #6 failed at 161.
6 out of 6 hunks failed while patching Makefile
Created attachment 206596 [details]
poudriere testport log for blender-2.80 (gzipped)
The reported bug still exists for the new version of the port committed in bug #239589. I have attached the poudriere testport log.
Created attachment 206597 [details]
Proposed patch (Subversion diff for blender-2.80_1)
I propose the attached patch to modify LDFLAGS to use the LLVM linker where it is available. I have also attached the poudriere testport log and portlint -C output for my proposed blender-2.80_1 patch.
Created attachment 206598 [details]
poudriere testport log for proposed blender-2.80_1 (gzipped)
Created attachment 206599 [details]
portlint -C output for proposed patch blender-2.80_1
CC jbeich@, @emaste and @bdrewery as to whether the approach in attachment 206597 [details] is the best/most appropriate one given their involvement/changes to the Mk/bsd.port.mk section on LLD_* and its relevant checks
Since reporting this bug I have also experienced the same issue with graphics/geeqie and multimedia/ffmpegthumbnailer. The workaround of setting LDFLAGS+= -fuse-ld=lld allows them to compile successfully.
(In reply to Ross McKelvie from comment #14)
Thank you Ross, if you could open separate bugs for these if they haven't already been reported, that would be appreciated. Feel free to add this issue ID to their "See Also" fields.
Can it be fixed with attachment 210054 [details] posted to bug 239567?