fwts-22.03.00 build fix patch

[ivanhu]

Hi Orbea,

I resent your last patch with correct commit format which can be applied
to FWTS for testing.

http://patchwork.ozlabs.org/project/fwts/patch/20220531074030.8151-1-ivan.hu@canonical.com/

Please check on it, then we can do the review and testing.

Cheers,
Ivan

On 5/28/22 04:34, orbea wrote:
> Hi Ivan,
>
> I would really appreciate it if you can test the latest version of the
> patch!
>
> On Wed, 18 May 2022 08:34:34 -0700
> orbea <orbea at riseup.net> wrote:
>
>> Thank you for testing! I attached one more version of the patch that I
>> think should fix the remaining issue. I would really appreciate it if
>> you can test it again.
>>
>> My last version of the patch fixed most of the issues and only one
>> more is left. I think this is because I was overzealous in removing
>> -lbsd when linking the fwts binary. Adding it back should get the
>> build to build completely this time.
>>
>> It is surprising to me how much the difference between gentoo and
>> ubuntu can matter here even when I test with GNU libtool, but I think
>> it should be possible to find a solution that works for everyone. :)
>>
>> On Wed, 18 May 2022 22:33:00 +0800
>> ivanhu <ivan.hu at canonical.com> wrote:
>>
>>> Still all build fail, you can check on
>>>
>>> https://launchpad.net/~firmware-testing-team/+archive/ubuntu/scratch/+packages
>>>
>>> It may be a good idea if you can create a folder/script for slibtool
>>> build like fedora rpm build with FWTS, instead of directly modifying
>>> configure.ac and makefile.am. It is easier for you to maintain and
>>> won't affect the other architectures build.
>>>
>>>
>>> Cheers,
>>> Ivan
>>>
>>> On 5/18/22 03:12, orbea wrote:  
>>>> Thank you, that was very helpful. I attached a new patch, can you
>>>> please try again?
>>>>
>>>> I think the problem was that I accidentally forgot AC_SUBST in
>>>> configure.ac which passes the GIO_LIBS and GLIB_LIBS variables to
>>>> the Makefiles. I'm surprised it worked for me at all without
>>>> this...
>>>>
>>>> On Tue, 17 May 2022 16:51:55 +0800
>>>> ivanhu <ivan.hu at canonical.com> wrote:
>>>>    
>>>>> I create a test build for all arch, you can check on
>>>>> https://launchpad.net/~firmware-testing-team/+archive/ubuntu/scratch/+packages
>>>>>
>>>>> For the amd64 build log for jammy,
>>>>> https://launchpadlibrarian.net/601665740/buildlog_ubuntu-jammy-amd64.fwts_22.03.01-0ubuntu1~j_BUILDING.txt.gz
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Ivan
>>>>>
>>>>> On 5/16/22 21:37, orbea wrote:    
>>>>>> Can you please share the build log? Perhaps I can find a better
>>>>>> way to do something?
>>>>>>
>>>>>> On Mon, 16 May 2022 14:48:16 +0800
>>>>>> ivanhu <ivan.hu at canonical.com> wrote:
>>>>>>       
>>>>>>> This modification make build fail on my machine.
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Ivan
>>>>>>>
>>>>>>> On 5/12/22 00:43, orbea wrote:    
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> When building fwts with slibtool
>>>>>>>> (https://dev.midipix.org/cross/slibtool) the build fail with
>>>>>>>> undefined references. This is because the build system is
>>>>>>>> using -lfoo linker flags for internal dependencies instead of
>>>>>>>> using the libtool archive (.la) files instead. Additionally
>>>>>>>> there are several instances of hardcoded pkg-config calls and
>>>>>>>> linker flags in LDFLAGS rather than LIBADD and LDADD.
>>>>>>>>
>>>>>>>> I attached a patch that fixes the issues by doing a few
>>>>>>>> things.
>>>>>>>>
>>>>>>>> * Removed hardcoded pkg-config calls and replaced them with
>>>>>>>>     PKG_CHECK_MODULES as needed.
>>>>>>>>
>>>>>>>> * Clearly delimited LDFLAGS from LDADD and LIBADD. Build
>>>>>>>> systems should only add non-dependency linker flags to
>>>>>>>> LDFLAGS while LDADD and LIBADD should be for any required
>>>>>>>> dependencies.
>>>>>>>>
>>>>>>>> * Removed any -lfoo linker flags for internal dependencies and
>>>>>>>> added them as .la files to link the fwts binary which now uses
>>>>>>>>     -no-undefined. Using -lfoo linker flags should be only for
>>>>>>>> external dependencies and often results in undefined errors or
>>>>>>>> the linker flags entirely not found with slibtool. Slibtool is
>>>>>>>> far more strict about user error than GNU libtool which often
>>>>>>>> silently hides such issues.
>>>>>>>>
>>>>>>>> * Cleared out a few unneeded or redundant linker flags.
>>>>>>>>
>>>>>>>> Gentoo bug: https://bugs.gentoo.org/780372
>>>>>>>>