[Buildroot] [PATCH 1/1] package/musl-fts: always build static library

[Buildroot] [PATCH 1/1] package/musl-fts: always build static library

[lancethepants]

musl-fts provides features left out of musl that are included in other libc's.

This patch always enables building the static library so
that it is always present with musl's libc.a when enabled.

For those that are using buildroot for toolchain creation
and want to static link, then libfts.a is available.

Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
Signed-off-by: lancethepants <lancethepants@gmail.com>
---
 package/musl-fts/musl-fts.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/musl-fts/musl-fts.mk b/package/musl-fts/musl-fts.mk
index dd7f1f9ea0..fcad9c3d75 100644
--- a/package/musl-fts/musl-fts.mk
+++ b/package/musl-fts/musl-fts.mk
@@ -12,5 +12,6 @@ MUSL_FTS_LICENSE_FILES = COPYING
 # pkg-config needed for autoreconf
 MUSL_FTS_DEPENDENCIES = host-pkgconf
 MUSL_FTS_INSTALL_STAGING = YES
+MUSL_FTS_CONF_OPTS += --enable-static
 
 $(eval $(autotools-package))
-- 
2.20.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/musl-fts: always build static library

[Yann E. MORIN]

Lance, All,

Please, be sure that the From header matches your SoB line; evne though
your email matches, the From lacks your real name.

On 2022-08-24 14:26 -0600, lancethepants spake thusly:
> musl-fts provides features left out of musl that are included in other libc's.
> 
> This patch always enables building the static library so
> that it is always present with musl's libc.a when enabled.
> 
> For those that are using buildroot for toolchain creation
> and want to static link, then libfts.a is available.

Sorry, I am not sure I totally understood what you meant here.

If I understood correctly, you want to use Buildroot, to generate a
musl-based toolchain, that you can distribute. You want that that
toolchain be usable to do both shared and static linking. Right?

Then you want to be able to use that toolchain to build some software
that uses fts(3). And so, since you want to allow static-only linking,
you want that toolchain to also include the fts library as a static
library.

However, this is, in my opinion, problematic for a few reasons.

First, including musl-ftx under the toolchain denomination is wrong; it
no longer is a toolchain, but more of an SDK. Including musl-fts will
for example mean that that toolchain will not be reusable as an external
toolchain for Buildroot, because then musl-fts in the toolchain will
come conflicting with musl-fts the package in Buildroot.

Second, if you need both static and shared libraries, why don't you
build your SDK with BR2_SHARED_STATIC_LIBS to begin with? With that, we
pass both --enable-static --enable-shared when building autotools
packages (and musl-fts is an autotools package); see package/Makefile.in
lines 423-424.

Third, what makes musl-fts different from other libraries that may be
included in the SDK? If your external software needs other libraries,
and you do not have them in the SDK, then you'll have to build those
libraries first, and point your software buildsystem to use them; why
can't you do the same for musl-fts?

> Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
> Signed-off-by: lancethepants <lancethepants@gmail.com>

That second SoB line is incorrect, as it has no real-name part; it is
also superfluous, because it is the same email part.

Regards,
Yann E. MORIN.

> ---
>  package/musl-fts/musl-fts.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/musl-fts/musl-fts.mk b/package/musl-fts/musl-fts.mk
> index dd7f1f9ea0..fcad9c3d75 100644
> --- a/package/musl-fts/musl-fts.mk
> +++ b/package/musl-fts/musl-fts.mk
> @@ -12,5 +12,6 @@ MUSL_FTS_LICENSE_FILES = COPYING
>  # pkg-config needed for autoreconf
>  MUSL_FTS_DEPENDENCIES = host-pkgconf
>  MUSL_FTS_INSTALL_STAGING = YES
> +MUSL_FTS_CONF_OPTS += --enable-static
>  
>  $(eval $(autotools-package))
> -- 
> 2.20.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/musl-fts: always build static library

[Lance Fredrickson]

On 8/27/2022 7:38 AM, Yann E. MORIN spake thusly:
> Lance, All,
>
> Please, be sure that the From header matches your SoB line; evne though
> your email matches, the From lacks your real name.
>
> On 2022-08-24 14:26 -0600, lancethepants spake thusly:
>> musl-fts provides features left out of musl that are included in other libc's.
>>
>> This patch always enables building the static library so
>> that it is always present with musl's libc.a when enabled.
>>
>> For those that are using buildroot for toolchain creation
>> and want to static link, then libfts.a is available.
> Sorry, I am not sure I totally understood what you meant here.
>
> If I understood correctly, you want to use Buildroot, to generate a
> musl-based toolchain, that you can distribute. You want that that
> toolchain be usable to do both shared and static linking. Right?
>
> Then you want to be able to use that toolchain to build some software
> that uses fts(3). And so, since you want to allow static-only linking,
> you want that toolchain to also include the fts library as a static
> library.

Yes, that is correct.
> However, this is, in my opinion, problematic for a few reasons.
>
> First, including musl-ftx under the toolchain denomination is wrong; it
> no longer is a toolchain, but more of an SDK. Including musl-fts will
> for example mean that that toolchain will not be reusable as an external
> toolchain for Buildroot, because then musl-fts in the toolchain will
> come conflicting with musl-fts the package in Buildroot.
I see the issue you're saying here.

> Second, if you need both static and shared libraries, why don't you
> build your SDK with BR2_SHARED_STATIC_LIBS to begin with? With that, we
> pass both --enable-static --enable-shared when building autotools
> packages (and musl-fts is an autotools package); see package/Makefile.in
> lines 423-424.
This is a good solution.
> Third, what makes musl-fts different from other libraries that may be
> included in the SDK? If your external software needs other libraries,
> and you do not have them in the SDK, then you'll have to build those
> libraries first, and point your software buildsystem to use them; why
> can't you do the same for musl-fts?
This is also a good solution.

"what makes musl-fts different from other libraries....?"
Well it is a library that has libc functionality. I can compile a glibc 
or uclibc toolchain and fts is included. Buildroot's musl toolchain 
includes musl-compat-headers to complete some of it's functionality, and 
musl-fts would be the same. For that reason I see it as a core toolchain 
component and not as something additional as an sdk. I do know that the 
musl developers are very intentional on what is included and on 
correctness, and fts didn't make the cut in their estimation. If fts 
were to be included as part of the musl toolchain in buildroot I now 
understand that solution would look different from my submission.

However, after grepping through the source I see that barely any 
packages in buildroot are dependent on it.  Perhaps other toolchain 
makers omit it as well and so the current fts strategy would be 
necessary if using those as an external toolchain.
Thanks for your response, you've given me some good workable solutions 
and I'll run with one of those.
>> Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
>> Signed-off-by: lancethepants <lancethepants@gmail.com>
Oopsie on my part. I manually added the first line but then I didn't 
catch that...
git format-patch -M -n -s -o outgoing origin/master
adds one as well using my git config.
> That second SoB line is incorrect, as it has no real-name part; it is
> also superfluous, because it is the same email part.
>
> Regards,
> Yann E. MORIN.
>
>> ---
>>   package/musl-fts/musl-fts.mk | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/package/musl-fts/musl-fts.mk b/package/musl-fts/musl-fts.mk
>> index dd7f1f9ea0..fcad9c3d75 100644
>> --- a/package/musl-fts/musl-fts.mk
>> +++ b/package/musl-fts/musl-fts.mk
>> @@ -12,5 +12,6 @@ MUSL_FTS_LICENSE_FILES = COPYING
>>   # pkg-config needed for autoreconf
>>   MUSL_FTS_DEPENDENCIES = host-pkgconf
>>   MUSL_FTS_INSTALL_STAGING = YES
>> +MUSL_FTS_CONF_OPTS += --enable-static
>>   
>>   $(eval $(autotools-package))
>> -- 
>> 2.20.1
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot@buildroot.org
>> https://lists.buildroot.org/mailman/listinfo/buildroot

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/musl-fts: always build static library

[Yann E. MORIN]

Lance, All,

On 2022-08-29 08:52 -0600, Lance Fredrickson spake thusly:
> On 8/27/2022 7:38 AM, Yann E. MORIN spake thusly:
> >On 2022-08-24 14:26 -0600, lancethepants spake thusly:
> >>musl-fts provides features left out of musl that are included in other libc's.
> >>This patch always enables building the static library so
> >>that it is always present with musl's libc.a when enabled.
[--SNIP--]
> "what makes musl-fts different from other libraries....?"
> Well it is a library that has libc functionality. I can compile a glibc or
> uclibc toolchain and fts is included. Buildroot's musl toolchain includes
> musl-compat-headers to complete some of it's functionality, and musl-fts
> would be the same. For that reason I see it as a core toolchain component
> and not as something additional as an sdk. I do know that the musl
> developers are very intentional on what is included and on correctness, and
> fts didn't make the cut in their estimation. If fts were to be included as
> part of the musl toolchain in buildroot I now understand that solution would
> look different from my submission.

There would still be a difference anyway. With glibc, fts is built-in to
the C library, while with musl and uclibc, and thus with musl-fts, they
are in a separate library, so your packages still need to know the
difference as they would need to explicitly link to that library.

> Thanks for your response, you've given me some good workable solutions and
> I'll run with one of those.

Great! :-)  I've thus marked your patch as rejected in Patchwork.

Thanks for the feedback.

Regards,
Yann E. MORIN.

> >>Signed-off-by: Lance Fredrickson <lancethepants@gmail.com>
> >>Signed-off-by: lancethepants <lancethepants@gmail.com>
> Oopsie on my part. I manually added the first line but then I didn't catch
> that...
> git format-patch -M -n -s -o outgoing origin/master
> adds one as well using my git config.
> >That second SoB line is incorrect, as it has no real-name part; it is
> >also superfluous, because it is the same email part.
> >
> >Regards,
> >Yann E. MORIN.
> >
> >>---
> >>  package/musl-fts/musl-fts.mk | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >>diff --git a/package/musl-fts/musl-fts.mk b/package/musl-fts/musl-fts.mk
> >>index dd7f1f9ea0..fcad9c3d75 100644
> >>--- a/package/musl-fts/musl-fts.mk
> >>+++ b/package/musl-fts/musl-fts.mk
> >>@@ -12,5 +12,6 @@ MUSL_FTS_LICENSE_FILES = COPYING
> >>  # pkg-config needed for autoreconf
> >>  MUSL_FTS_DEPENDENCIES = host-pkgconf
> >>  MUSL_FTS_INSTALL_STAGING = YES
> >>+MUSL_FTS_CONF_OPTS += --enable-static
> >>  $(eval $(autotools-package))
> >>-- 
> >>2.20.1
> >>
> >>_______________________________________________
> >>buildroot mailing list
> >>buildroot@buildroot.org
> >>https://lists.buildroot.org/mailman/listinfo/buildroot
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot