Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Andreas Ziegler]

Hi Nicolas,

On 2022-06-04 11:15, Nicolas Carrier <nicolas.carrier@orolia.com> wrote:

> Shoot, apparently, I failed when testing yesterday.
> The ulog build issue is present on master too, contrary to what I said 
> earlier.
> 
> So now, we have no clue at all :/

Alchemy is missing the correct library path for the Buildroot staging 
directory.

This is the environment when alchemy is called from Buildroot:

ALCHEMY_TARGET_ENV = \
	$(TARGET_MAKE_ENV) \
	ALCHEMY_HOME=$(ALCHEMY_HOME) \
	ALCHEMY_WORKSPACE_DIR="$(@D)" \
	ALCHEMY_TARGET_OUT=alchemy-out \
	PKGCONFIG_BIN=$(PKG_CONFIG_HOST_BINARY) \
	TARGET_OS=linux \
	TARGET_OS_FLAVOUR=buildroot \
	TARGET_CROSS="$(TARGET_CROSS)" \
	TARGET_ARCH=xxx \
	TARGET_GLOBAL_CXXFLAGS="$(TARGET_CXXFLAGS)" \
	TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS)" \
	                       ^ LDFLAGS are usually empty
	TARGET_GLOBAL_FFLAGS="$(TARGET_FCFLAGS)" \
	TARGET_GLOBAL_FCFLAGS="$(TARGET_FCFLAGS)"

Alchemy adds more settings to LDFLAGS, this is the final content:

+ TARGET_GLOBAL_LDFLAGS = -O2 -Wl,-O1 
-Lalchemy-out/staging/lib/arm-linux-gnueabihf -Lalchemy-out/staging/lib 
-Lalchemy-out/staging/usr/lib/arm-linux-gnueabihf 
-Lalchemy-out/staging/usr/lib 
-Wl,-rpath-link=alchemy-out/staging/lib/arm-linux-gnueabihf 
-Wl,-rpath-link=alchemy-out/staging/lib 
-Wl,-rpath-link=alchemy-out/staging/usr/lib/arm-linux-gnueabihf 
-Wl,-rpath-link=alchemy-out/staging/usr/lib

Adding the Buildroot staging library path to LDFLAGS makes the build 
succeed:

	...
	TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib" \
	...

This is just a workaround; ideally Buildroot should establish itself as 
a toolchain 'flavour'. Unfortunately, alchemy is not very well 
documented :-[

Kind regards,
Andreas


> On Fri, 2022-06-03 at 12:51 +0200, Nicolas Carrier wrote:
>> And I redid the test with the working config (that is, without the 
>> SYSTEMD line) and this time
>> there
>> are only:
>> 
>> output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/usr/lib/libpthread.so: 
>> ASCII text
>> output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so:????? 
>> ASCII text
>> 
>> But their content is the same:
>> 
>> /* GNU ld script
>> ?? Use the shared library, but some functions are only in
>> ?? the static library, so try that secondarily.? */
>> OUTPUT_FORMAT(elf32-littlearm)
>> GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
>> 
>> 
>> On Fri, 2022-06-03 at 12:44 +0200, Nicolas Carrier wrote:
>> > Great, at least, I'm not alone :)
>> >
>> > One other thing to notice is that there libpthread.so ascii files in the output directory, the
>> > content of which doesn't seem correct:
>> >
>> > output/build/ulog-0389d243352255f6182326dccdae3d56dadc078f/alchemy-
>> > out/staging/lib/libpthread.so:
>> > ASCII text
>> > output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/usr/lib/libpthread.so:???????????????????
>> > ASCII text
>> > output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so:????????????????????????
>> > ASCII text
>> >
>> > They all contain:
>> >
>> > /* GNU ld script
>> > ?? Use the shared library, but some functions are only in
>> > ?? the static library, so try that secondarily.? */
>> > OUTPUT_FORMAT(elf32-littlearm)
>> > GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
>> >
>> >
>> > On Fri, 2022-06-03 at 11:47 +0200, Thomas Petazzoni wrote:
>> > > CAUTION: This email originated from outside of the organization.
>> > > Do not click links or open attachments unless you recognize the sender and know the content is
>> > > safe.
>> > >
>> > > On Fri, 03 Jun 2022 11:09:48 +0200
>> > > Nicolas Carrier <nicolas.carrier@orolia.com> wrote:
>> > >
>> > > > Hello,
>> > > > I tested this morning against the master of buildroot (with an ubuntu 20.04) and the issue
>> > > > doesn't
>> > > > appear anymore.
>> > > > So there must be some change "recently" merged, which solves the issue.
>> > > >
>> > > > An idea anyone?
>> > >
>> > > Not yet an idea, but I confirm that I was able to reproduce on
>> > > 2022.02.2 (just so you know that your e-mail and issue have been seen!)
>> > >
>> > > Thomas
>> > > --
>> > > Thomas Petazzoni, co-owner and CEO, Bootlin
>> > > Embedded Linux and Kernel engineering and training
>> > > https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Thomas Petazzoni via buildroot]

Hello Andreas,

On Sun, 05 Jun 2022 06:05:09 +0000
Andreas Ziegler <br015@umbiko.net> wrote:

> This is the environment when alchemy is called from Buildroot:
> 
> ALCHEMY_TARGET_ENV = \
> 	$(TARGET_MAKE_ENV) \
> 	ALCHEMY_HOME=$(ALCHEMY_HOME) \
> 	ALCHEMY_WORKSPACE_DIR="$(@D)" \
> 	ALCHEMY_TARGET_OUT=alchemy-out \
> 	PKGCONFIG_BIN=$(PKG_CONFIG_HOST_BINARY) \
> 	TARGET_OS=linux \
> 	TARGET_OS_FLAVOUR=buildroot \
> 	TARGET_CROSS="$(TARGET_CROSS)" \
> 	TARGET_ARCH=xxx \
> 	TARGET_GLOBAL_CXXFLAGS="$(TARGET_CXXFLAGS)" \
> 	TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS)" \
> 	                       ^ LDFLAGS are usually empty
> 	TARGET_GLOBAL_FFLAGS="$(TARGET_FCFLAGS)" \
> 	TARGET_GLOBAL_FCFLAGS="$(TARGET_FCFLAGS)"
> 
> Alchemy adds more settings to LDFLAGS, this is the final content:
> 
> + TARGET_GLOBAL_LDFLAGS = -O2 -Wl,-O1 
> -Lalchemy-out/staging/lib/arm-linux-gnueabihf -Lalchemy-out/staging/lib 
> -Lalchemy-out/staging/usr/lib/arm-linux-gnueabihf 
> -Lalchemy-out/staging/usr/lib 
> -Wl,-rpath-link=alchemy-out/staging/lib/arm-linux-gnueabihf 
> -Wl,-rpath-link=alchemy-out/staging/lib 
> -Wl,-rpath-link=alchemy-out/staging/usr/lib/arm-linux-gnueabihf 
> -Wl,-rpath-link=alchemy-out/staging/usr/lib
> 
> Adding the Buildroot staging library path to LDFLAGS makes the build 
> succeed:
> 
> 	...
> 	TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib" \

Thanks for your investigation!

-L$(STAGING_DIR)/usr/lib should normally not be needed, because
$(STAGING_DIR)/usr/lib is in the default search path of the
cross-compiler, as the compiler has $(STAGING_DIR)/usr as its sysroot.

So from a cross-compiler perspective, -L$(STAGING_DIR)/usr/lib should
normally not be needed, and that's why it's not in $(TARGET_LDFLAGS).

Also, there is a curious thing in the report from Nicolas: the error
happens when systemd is enabled, but doesn't happen when systemd is
disabled.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Andreas Ziegler]

Hi Thomas,

On 2022-06-05 07:06, Thomas Petazzoni wrote:
> Hello Andreas,
> 
> On Sun, 05 Jun 2022 06:05:09 +0000
> Andreas Ziegler <br015@umbiko.net> wrote:
> 
>> This is the environment when alchemy is called from Buildroot:
>> 
>> ALCHEMY_TARGET_ENV = \
>> 	$(TARGET_MAKE_ENV) \
>> 	ALCHEMY_HOME=$(ALCHEMY_HOME) \
>> 	ALCHEMY_WORKSPACE_DIR="$(@D)" \
>> 	ALCHEMY_TARGET_OUT=alchemy-out \
>> 	PKGCONFIG_BIN=$(PKG_CONFIG_HOST_BINARY) \
>> 	TARGET_OS=linux \
>> 	TARGET_OS_FLAVOUR=buildroot \
>> 	TARGET_CROSS="$(TARGET_CROSS)" \
>> 	TARGET_ARCH=xxx \
>> 	TARGET_GLOBAL_CXXFLAGS="$(TARGET_CXXFLAGS)" \
>> 	TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS)" \
>> 	                       ^ LDFLAGS are usually empty
>> 	TARGET_GLOBAL_FFLAGS="$(TARGET_FCFLAGS)" \
>> 	TARGET_GLOBAL_FCFLAGS="$(TARGET_FCFLAGS)"
>> 
>> Alchemy adds more settings to LDFLAGS, this is the final content:
>> 
>> + TARGET_GLOBAL_LDFLAGS = -O2 -Wl,-O1
>> -Lalchemy-out/staging/lib/arm-linux-gnueabihf 
>> -Lalchemy-out/staging/lib
>> -Lalchemy-out/staging/usr/lib/arm-linux-gnueabihf
>> -Lalchemy-out/staging/usr/lib
>> -Wl,-rpath-link=alchemy-out/staging/lib/arm-linux-gnueabihf
>> -Wl,-rpath-link=alchemy-out/staging/lib
>> -Wl,-rpath-link=alchemy-out/staging/usr/lib/arm-linux-gnueabihf
>> -Wl,-rpath-link=alchemy-out/staging/usr/lib
>> 
>> Adding the Buildroot staging library path to LDFLAGS makes the build
>> succeed:
>> 
>> 	...
>> 	TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib" \
> 
> Thanks for your investigation!
> 
> -L$(STAGING_DIR)/usr/lib should normally not be needed, because
> $(STAGING_DIR)/usr/lib is in the default search path of the
> cross-compiler, as the compiler has $(STAGING_DIR)/usr as its sysroot.
> 
> So from a cross-compiler perspective, -L$(STAGING_DIR)/usr/lib should
> normally not be needed, and that's why it's not in $(TARGET_LDFLAGS).

And sysroot is detected by alchemy:

+ TARGET_TOOLCHAIN_SYSROOT = 
/home/data/test/autobuild/host/arm-buildroot-linux-gnueabihf/sysroot

> Also, there is a curious thing in the report from Nicolas: the error
> happens when systemd is enabled, but doesn't happen when systemd is
> disabled.

I can confirm this. Adding BR2_INIT_SYSTEMD=y breaks the build (using 
make clean && make ulog).

Kind regards,
Andreas

> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Romain Naour]

Hello,

Le 05/06/2022 à 13:46, Andreas Ziegler a écrit :
> Hi Thomas,
> 
> On 2022-06-05 07:06, Thomas Petazzoni wrote:
>> Hello Andreas,
>>
>> On Sun, 05 Jun 2022 06:05:09 +0000
>> Andreas Ziegler <br015@umbiko.net> wrote:
>>
>>> This is the environment when alchemy is called from Buildroot:
>>>
>>> ALCHEMY_TARGET_ENV = \
>>>     $(TARGET_MAKE_ENV) \
>>>     ALCHEMY_HOME=$(ALCHEMY_HOME) \
>>>     ALCHEMY_WORKSPACE_DIR="$(@D)" \
>>>     ALCHEMY_TARGET_OUT=alchemy-out \
>>>     PKGCONFIG_BIN=$(PKG_CONFIG_HOST_BINARY) \
>>>     TARGET_OS=linux \
>>>     TARGET_OS_FLAVOUR=buildroot \
>>>     TARGET_CROSS="$(TARGET_CROSS)" \
>>>     TARGET_ARCH=xxx \
>>>     TARGET_GLOBAL_CXXFLAGS="$(TARGET_CXXFLAGS)" \
>>>     TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS)" \
>>>                            ^ LDFLAGS are usually empty
>>>     TARGET_GLOBAL_FFLAGS="$(TARGET_FCFLAGS)" \
>>>     TARGET_GLOBAL_FCFLAGS="$(TARGET_FCFLAGS)"
>>>
>>> Alchemy adds more settings to LDFLAGS, this is the final content:
>>>
>>> + TARGET_GLOBAL_LDFLAGS = -O2 -Wl,-O1
>>> -Lalchemy-out/staging/lib/arm-linux-gnueabihf -Lalchemy-out/staging/lib
>>> -Lalchemy-out/staging/usr/lib/arm-linux-gnueabihf
>>> -Lalchemy-out/staging/usr/lib
>>> -Wl,-rpath-link=alchemy-out/staging/lib/arm-linux-gnueabihf
>>> -Wl,-rpath-link=alchemy-out/staging/lib
>>> -Wl,-rpath-link=alchemy-out/staging/usr/lib/arm-linux-gnueabihf
>>> -Wl,-rpath-link=alchemy-out/staging/usr/lib
>>>
>>> Adding the Buildroot staging library path to LDFLAGS makes the build
>>> succeed:
>>>
>>>     ...
>>>     TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib" \
>>
>> Thanks for your investigation!
>>
>> -L$(STAGING_DIR)/usr/lib should normally not be needed, because
>> $(STAGING_DIR)/usr/lib is in the default search path of the
>> cross-compiler, as the compiler has $(STAGING_DIR)/usr as its sysroot.
>>
>> So from a cross-compiler perspective, -L$(STAGING_DIR)/usr/lib should
>> normally not be needed, and that's why it's not in $(TARGET_LDFLAGS).
> 
> And sysroot is detected by alchemy:
> 
> + TARGET_TOOLCHAIN_SYSROOT =
> /home/data/test/autobuild/host/arm-buildroot-linux-gnueabihf/sysroot

Yes but alchemy try to copy some files from staging directory to
ulog/alchemy-out/staging

See _libc_installed_file target in output/host/opt/alchemy/toolchains/libc.mk.

If we hack into _libc_installed_file rule to not copy any files from staging,
the build succeed.

> 
>> Also, there is a curious thing in the report from Nicolas: the error
>> happens when systemd is enabled, but doesn't happen when systemd is
>> disabled.
> 
> I can confirm this. Adding BR2_INIT_SYSTEMD=y breaks the build (using make clean
> && make ulog).

I did a try without systemd but the build failed.

Best regards,
Romain


> 
> Kind regards,
> Andreas
> 
>> Thomas
>> -- 
>> Thomas Petazzoni, co-owner and CEO, Bootlin
>> Embedded Linux and Kernel engineering and training
>> https://bootlin.com
> _______________________________________________
> 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] ulog compilation issue with buildroot 2022.02.2

[Tim Hammer]

Greetings all -

On Sun, Jun 05, 2022 at 04:01:17PM +0200, Romain Naour wrote:
> Hello,
> 
> Le 05/06/2022 à 13:46, Andreas Ziegler a écrit :
> > Hi Thomas,
> > 
> > On 2022-06-05 07:06, Thomas Petazzoni wrote:
> >> Hello Andreas,
> >>
> >> On Sun, 05 Jun 2022 06:05:09 +0000
> >> Andreas Ziegler <br015@umbiko.net> wrote:
> >>
> >>> This is the environment when alchemy is called from Buildroot:
> >>>
> >>> ALCHEMY_TARGET_ENV = \
> >>>     $(TARGET_MAKE_ENV) \
> >>>     ALCHEMY_HOME=$(ALCHEMY_HOME) \
> >>>     ALCHEMY_WORKSPACE_DIR="$(@D)" \
> >>>     ALCHEMY_TARGET_OUT=alchemy-out \
> >>>     PKGCONFIG_BIN=$(PKG_CONFIG_HOST_BINARY) \
> >>>     TARGET_OS=linux \
> >>>     TARGET_OS_FLAVOUR=buildroot \
> >>>     TARGET_CROSS="$(TARGET_CROSS)" \
> >>>     TARGET_ARCH=xxx \
> >>>     TARGET_GLOBAL_CXXFLAGS="$(TARGET_CXXFLAGS)" \
> >>>     TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS)" \
> >>>                            ^ LDFLAGS are usually empty
> >>>     TARGET_GLOBAL_FFLAGS="$(TARGET_FCFLAGS)" \
> >>>     TARGET_GLOBAL_FCFLAGS="$(TARGET_FCFLAGS)"
> >>>
> >>> Alchemy adds more settings to LDFLAGS, this is the final content:
> >>>
> >>> + TARGET_GLOBAL_LDFLAGS = -O2 -Wl,-O1
> >>> -Lalchemy-out/staging/lib/arm-linux-gnueabihf -Lalchemy-out/staging/lib
> >>> -Lalchemy-out/staging/usr/lib/arm-linux-gnueabihf
> >>> -Lalchemy-out/staging/usr/lib
> >>> -Wl,-rpath-link=alchemy-out/staging/lib/arm-linux-gnueabihf
> >>> -Wl,-rpath-link=alchemy-out/staging/lib
> >>> -Wl,-rpath-link=alchemy-out/staging/usr/lib/arm-linux-gnueabihf
> >>> -Wl,-rpath-link=alchemy-out/staging/usr/lib
> >>>
> >>> Adding the Buildroot staging library path to LDFLAGS makes the build
> >>> succeed:
> >>>
> >>>     ...
> >>>     TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib" \
> >>
> >> Thanks for your investigation!
> >>
> >> -L$(STAGING_DIR)/usr/lib should normally not be needed, because
> >> $(STAGING_DIR)/usr/lib is in the default search path of the
> >> cross-compiler, as the compiler has $(STAGING_DIR)/usr as its sysroot.
> >>
> >> So from a cross-compiler perspective, -L$(STAGING_DIR)/usr/lib should
> >> normally not be needed, and that's why it's not in $(TARGET_LDFLAGS).
> > 
> > And sysroot is detected by alchemy:
> > 
> > + TARGET_TOOLCHAIN_SYSROOT =
> > /home/data/test/autobuild/host/arm-buildroot-linux-gnueabihf/sysroot
> 
> Yes but alchemy try to copy some files from staging directory to
> ulog/alchemy-out/staging
> 

And it seems that the files copied is different between the working (w/o systemd)
and non-working (w/ systemd) builds.

Looking at sysroot in a working build, it only copies the two files from the lib/ directory:
    ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread_nonshared.a
    ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so
    ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.a
    ./host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread-2.25.so
    ./host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0

Whereas in the non-working build, the files are all in the usr/lib/ directory:
    ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread_nonshared.a
    ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread-2.25.so
    ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so
    ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.a
   ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so.0

In this case, it also copies the libpthread.so file which is an ld script where I think it
is getting the bad path:
    /* GNU ld script
       Use the shared library, but some functions are only in
       the static library, so try that secondarily.  */
    OUTPUT_FORMAT(elf32-littlearm)
    GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )

Is there something in the systemd configuration/build that is creating this script
file?


.Tim
Tim D. Hammer
tim.hammer@orolia.com


> See _libc_installed_file target in output/host/opt/alchemy/toolchains/libc.mk.
> 
> If we hack into _libc_installed_file rule to not copy any files from staging,
> the build succeed.
> 
> > 
> >> Also, there is a curious thing in the report from Nicolas: the error
> >> happens when systemd is enabled, but doesn't happen when systemd is
> >> disabled.
> > 
> > I can confirm this. Adding BR2_INIT_SYSTEMD=y breaks the build (using make clean
> > && make ulog).
> 
> I did a try without systemd but the build failed.
> 
> Best regards,
> Romain
> 
> 
> > 
> > Kind regards,
> > Andreas
> > 
> >> Thomas
> >> -- 
> >> Thomas Petazzoni, co-owner and CEO, Bootlin
> >> Embedded Linux and Kernel engineering and training
> >> https://bootlin.com
> > _______________________________________________
> > 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
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Arnout Vandecappelle]

On 06/06/2022 16:27, Tim Hammer wrote:
> 
> Greetings all -
> 
> On Sun, Jun 05, 2022 at 04:01:17PM +0200, Romain Naour wrote:
>> Hello,
>>
>> Le 05/06/2022 à 13:46, Andreas Ziegler a écrit :
>>> Hi Thomas,
>>>
>>> On 2022-06-05 07:06, Thomas Petazzoni wrote:
>>>> Hello Andreas,
>>>>
>>>> On Sun, 05 Jun 2022 06:05:09 +0000
>>>> Andreas Ziegler <br015@umbiko.net> wrote:
>>>>
>>>>> This is the environment when alchemy is called from Buildroot:
>>>>>
>>>>> ALCHEMY_TARGET_ENV = \
>>>>>      $(TARGET_MAKE_ENV) \
>>>>>      ALCHEMY_HOME=$(ALCHEMY_HOME) \
>>>>>      ALCHEMY_WORKSPACE_DIR="$(@D)" \
>>>>>      ALCHEMY_TARGET_OUT=alchemy-out \
>>>>>      PKGCONFIG_BIN=$(PKG_CONFIG_HOST_BINARY) \
>>>>>      TARGET_OS=linux \
>>>>>      TARGET_OS_FLAVOUR=buildroot \
>>>>>      TARGET_CROSS="$(TARGET_CROSS)" \
>>>>>      TARGET_ARCH=xxx \
>>>>>      TARGET_GLOBAL_CXXFLAGS="$(TARGET_CXXFLAGS)" \
>>>>>      TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS)" \
>>>>>                             ^ LDFLAGS are usually empty
>>>>>      TARGET_GLOBAL_FFLAGS="$(TARGET_FCFLAGS)" \
>>>>>      TARGET_GLOBAL_FCFLAGS="$(TARGET_FCFLAGS)"
>>>>>
>>>>> Alchemy adds more settings to LDFLAGS, this is the final content:
>>>>>
>>>>> + TARGET_GLOBAL_LDFLAGS = -O2 -Wl,-O1
>>>>> -Lalchemy-out/staging/lib/arm-linux-gnueabihf -Lalchemy-out/staging/lib
>>>>> -Lalchemy-out/staging/usr/lib/arm-linux-gnueabihf
>>>>> -Lalchemy-out/staging/usr/lib
>>>>> -Wl,-rpath-link=alchemy-out/staging/lib/arm-linux-gnueabihf
>>>>> -Wl,-rpath-link=alchemy-out/staging/lib
>>>>> -Wl,-rpath-link=alchemy-out/staging/usr/lib/arm-linux-gnueabihf
>>>>> -Wl,-rpath-link=alchemy-out/staging/usr/lib
>>>>>
>>>>> Adding the Buildroot staging library path to LDFLAGS makes the build
>>>>> succeed:
>>>>>
>>>>>      ...
>>>>>      TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib" \
>>>>
>>>> Thanks for your investigation!
>>>>
>>>> -L$(STAGING_DIR)/usr/lib should normally not be needed, because
>>>> $(STAGING_DIR)/usr/lib is in the default search path of the
>>>> cross-compiler, as the compiler has $(STAGING_DIR)/usr as its sysroot.
>>>>
>>>> So from a cross-compiler perspective, -L$(STAGING_DIR)/usr/lib should
>>>> normally not be needed, and that's why it's not in $(TARGET_LDFLAGS).
>>>
>>> And sysroot is detected by alchemy:
>>>
>>> + TARGET_TOOLCHAIN_SYSROOT =
>>> /home/data/test/autobuild/host/arm-buildroot-linux-gnueabihf/sysroot
>>
>> Yes but alchemy try to copy some files from staging directory to
>> ulog/alchemy-out/staging
>>
> 
> And it seems that the files copied is different between the working (w/o systemd)
> and non-working (w/ systemd) builds.
> 
> Looking at sysroot in a working build, it only copies the two files from the lib/ directory:
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread_nonshared.a
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.a
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread-2.25.so
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/lib/libpthread.so.0
> 
> Whereas in the non-working build, the files are all in the usr/lib/ directory:
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread_nonshared.a
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread-2.25.so
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so
>      ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.a
>     ./host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so.0
> 
> In this case, it also copies the libpthread.so file which is an ld script where I think it
> is getting the bad path:
>      /* GNU ld script
>         Use the shared library, but some functions are only in
>         the static library, so try that secondarily.  */
>      OUTPUT_FORMAT(elf32-littlearm)
>      GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )

  With systemd, you automatically get BR2_ROOTFS_MERGED_USR, which means that 
/lib is a symlink to /usr/lib. So /lib/libpthread.so.0 should still be a correct 
path.


> Is there something in the systemd configuration/build that is creating this script
> file?

  No, it's normal that libpthread.so is a linker script. It gets installed in 
/lib by glibc - but with systemd, since /lib is a symlink to /usr/lib, it ends 
up there.


  I can't find back the original issue, but I suspect the problem is that 
ulog/alchemy calls ld directly (i.e. not gcc), which bypasses the toolchain 
wrapper and therefore bypasses the setting of sysroot. Although that doesn't 
explain why it would work on non-systemd (or non-merged-usr)...

  Regards,
  Arnout

> 
> 
> .Tim
> Tim D. Hammer
> tim.hammer@orolia.com
> 
> 
>> See _libc_installed_file target in output/host/opt/alchemy/toolchains/libc.mk.
>>
>> If we hack into _libc_installed_file rule to not copy any files from staging,
>> the build succeed.
>>
>>>
>>>> Also, there is a curious thing in the report from Nicolas: the error
>>>> happens when systemd is enabled, but doesn't happen when systemd is
>>>> disabled.
>>>
>>> I can confirm this. Adding BR2_INIT_SYSTEMD=y breaks the build (using make clean
>>> && make ulog).
>>
>> I did a try without systemd but the build failed.
>>
>> Best regards,
>> Romain
>>
>>
>>>
>>> Kind regards,
>>> Andreas
>>>
>>>> Thomas
>>>> -- 
>>>> Thomas Petazzoni, co-owner and CEO, Bootlin
>>>> Embedded Linux and Kernel engineering and training
>>>> https://bootlin.com
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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] ulog compilation issue with buildroot 2022.02.2

[Nicolas Carrier]

I confirm that the workaround works fine, thank you very much!

On Sun, 2022-06-05 at 11:46 +0000, Andreas Ziegler wrote:
> CAUTION: This email originated from outside of the organization.
> Do not click links or open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Thomas,
> 
> On 2022-06-05 07:06, Thomas Petazzoni wrote:
> > Hello Andreas,
> > 
> > On Sun, 05 Jun 2022 06:05:09 +0000
> > Andreas Ziegler <br015@umbiko.net> wrote:
> > 
> > > This is the environment when alchemy is called from Buildroot:
> > > 
> > > ALCHEMY_TARGET_ENV = \
> > >      $(TARGET_MAKE_ENV) \
> > >      ALCHEMY_HOME=$(ALCHEMY_HOME) \
> > >      ALCHEMY_WORKSPACE_DIR="$(@D)" \
> > >      ALCHEMY_TARGET_OUT=alchemy-out \
> > >      PKGCONFIG_BIN=$(PKG_CONFIG_HOST_BINARY) \
> > >      TARGET_OS=linux \
> > >      TARGET_OS_FLAVOUR=buildroot \
> > >      TARGET_CROSS="$(TARGET_CROSS)" \
> > >      TARGET_ARCH=xxx \
> > >      TARGET_GLOBAL_CXXFLAGS="$(TARGET_CXXFLAGS)" \
> > >      TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS)" \
> > >                             ^ LDFLAGS are usually empty
> > >      TARGET_GLOBAL_FFLAGS="$(TARGET_FCFLAGS)" \
> > >      TARGET_GLOBAL_FCFLAGS="$(TARGET_FCFLAGS)"
> > > 
> > > Alchemy adds more settings to LDFLAGS, this is the final content:
> > > 
> > > + TARGET_GLOBAL_LDFLAGS = -O2 -Wl,-O1
> > > -Lalchemy-out/staging/lib/arm-linux-gnueabihf
> > > -Lalchemy-out/staging/lib
> > > -Lalchemy-out/staging/usr/lib/arm-linux-gnueabihf
> > > -Lalchemy-out/staging/usr/lib
> > > -Wl,-rpath-link=alchemy-out/staging/lib/arm-linux-gnueabihf
> > > -Wl,-rpath-link=alchemy-out/staging/lib
> > > -Wl,-rpath-link=alchemy-out/staging/usr/lib/arm-linux-gnueabihf
> > > -Wl,-rpath-link=alchemy-out/staging/usr/lib
> > > 
> > > Adding the Buildroot staging library path to LDFLAGS makes the build
> > > succeed:
> > > 
> > >      ...
> > >      TARGET_GLOBAL_LDFLAGS="$(TARGET_LDFLAGS) -L$(STAGING_DIR)/usr/lib" \
> > 
> > Thanks for your investigation!
> > 
> > -L$(STAGING_DIR)/usr/lib should normally not be needed, because
> > $(STAGING_DIR)/usr/lib is in the default search path of the
> > cross-compiler, as the compiler has $(STAGING_DIR)/usr as its sysroot.
> > 
> > So from a cross-compiler perspective, -L$(STAGING_DIR)/usr/lib should
> > normally not be needed, and that's why it's not in $(TARGET_LDFLAGS).
> 
> And sysroot is detected by alchemy:
> 
> + TARGET_TOOLCHAIN_SYSROOT =
> /home/data/test/autobuild/host/arm-buildroot-linux-gnueabihf/sysroot
> 
> > Also, there is a curious thing in the report from Nicolas: the error
> > happens when systemd is enabled, but doesn't happen when systemd is
> > disabled.
> 
> I can confirm this. Adding BR2_INIT_SYSTEMD=y breaks the build (using
> make clean && make ulog).
> 
> Kind regards,
> Andreas
> 
> > Thomas
> > --
> > Thomas Petazzoni, co-owner and CEO, Bootlin
> > Embedded Linux and Kernel engineering and training
> > https://bootlin.com


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

[Buildroot] ulog compilation issue with buildroot 2022.02.2

[Nicolas Carrier]

Hello!

When using the following minimal config:

BR2_arm=y
BR2_cortex_a9=y
BR2_ARM_ENABLE_NEON=y
BR2_ARM_ENABLE_VFP=y
BR2_ARM_FPU_NEON=y
BR2_SSP_ALL=y
BR2_FORTIFY_SOURCE_2=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM=y
BR2_INIT_SYSTEMD=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
BR2_PACKAGE_ULOG=y

the build will fail when trying to build ulog with the following error message:

[...]
xxx C++: libulog <= libulog/ulog.cpp
xxx C: libulog <= libulog/ulog_read.c
xxx C: libulog <= libulog/ulog_write.c
xxx C: libulog <= libulog/ulog_write_android.c
xxx C: libulog <= libulog/ulog_write_bin.c
xxx C: libulog <= libulog/ulog_write_raw.c
SharedLib: libulog => alchemy-out/build/libulog/libulog.so
/home/ncarrier/workspace/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-
gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/libpthread.so.0
/home/ncarrier/workspace/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-
gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find /usr/lib/libpthread_nonshared.a
collect2: error: ld returned 1 exit status
make[1]: Leaving directory '/home/ncarrier/workspace/buildroot/output/build/ulog-
0389d243352255f6182326dccdae3d56dadc078f'
make[1]: ***
[/home/ncarrier/workspace/buildroot/output/host/opt/alchemy/classes/LIBRARY/rules.mk:25: alchemy-
out/build/libulog/libulog.so] Error 1
make: *** [package/pkg-generic.mk:293: /home/ncarrier/workspace/buildroot/output/build/ulog-
0389d243352255f6182326dccdae3d56dadc078f/.stamp_built] Error 2

From this traces, it looks like it is trying to link with /lib/libpthread.so.0, which can't work
since it's the pthread library of the system.


One thing to note is that, when BR2_INIT_SYSTEMD=y is removed from the config above, the build will
succeed.
So it looks like systemd or one of its dependencies, is enabling something which breaks ulog's
build.

Does anyone have an idea of what could possibly go wrong and maybe, of a workaround?
My host machine is a debian 11 amd64.

Thank you by advance :)

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

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Nicolas Carrier]

Hello,
I tested this morning against the master of buildroot (with an ubuntu 20.04) and the issue doesn't
appear anymore.
So there must be some change "recently" merged, which solves the issue.

An idea anyone?

On Thu, 2022-06-02 at 17:31 +0200, Nicolas Carrier wrote:
> Hello!
> 
> When using the following minimal config:
> 
> BR2_arm=y
> BR2_cortex_a9=y
> BR2_ARM_ENABLE_NEON=y
> BR2_ARM_ENABLE_VFP=y
> BR2_ARM_FPU_NEON=y
> BR2_SSP_ALL=y
> BR2_FORTIFY_SOURCE_2=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM=y
> BR2_INIT_SYSTEMD=y
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
> BR2_PACKAGE_ULOG=y
> 
> the build will fail when trying to build ulog with the following error message:
> 
> [...]
> xxx C++: libulog <= libulog/ulog.cpp
> xxx C: libulog <= libulog/ulog_read.c
> xxx C: libulog <= libulog/ulog_write.c
> xxx C: libulog <= libulog/ulog_write_android.c
> xxx C: libulog <= libulog/ulog_write_bin.c
> xxx C: libulog <= libulog/ulog_write_raw.c
> SharedLib: libulog => alchemy-out/build/libulog/libulog.so
> /home/ncarrier/workspace/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-
> gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/libpthread.so.0
> /home/ncarrier/workspace/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-linux-
> gnueabihf/7.3.1/../../../../arm-linux-gnueabihf/bin/ld: cannot find
> /usr/lib/libpthread_nonshared.a
> collect2: error: ld returned 1 exit status
> make[1]: Leaving directory '/home/ncarrier/workspace/buildroot/output/build/ulog-
> 0389d243352255f6182326dccdae3d56dadc078f'
> make[1]: ***
> [/home/ncarrier/workspace/buildroot/output/host/opt/alchemy/classes/LIBRARY/rules.mk:25: alchemy-
> out/build/libulog/libulog.so] Error 1
> make: *** [package/pkg-generic.mk:293: /home/ncarrier/workspace/buildroot/output/build/ulog-
> 0389d243352255f6182326dccdae3d56dadc078f/.stamp_built] Error 2
> 
> From this traces, it looks like it is trying to link with /lib/libpthread.so.0, which can't work
> since it's the pthread library of the system.
> 
> 
> One thing to note is that, when BR2_INIT_SYSTEMD=y is removed from the config above, the build
> will
> succeed.
> So it looks like systemd or one of its dependencies, is enabling something which breaks ulog's
> build.
> 
> Does anyone have an idea of what could possibly go wrong and maybe, of a workaround?
> My host machine is a debian 11 amd64.
> 
> Thank you by advance :)


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

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Thomas Petazzoni via buildroot]

On Fri, 03 Jun 2022 11:09:48 +0200
Nicolas Carrier <nicolas.carrier@orolia.com> wrote:

> Hello,
> I tested this morning against the master of buildroot (with an ubuntu 20.04) and the issue doesn't
> appear anymore.
> So there must be some change "recently" merged, which solves the issue.
> 
> An idea anyone?

Not yet an idea, but I confirm that I was able to reproduce on
2022.02.2 (just so you know that your e-mail and issue have been seen!)

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Nicolas Carrier]

Great, at least, I'm not alone :)

One other thing to notice is that there libpthread.so ascii files in the output directory, the
content of which doesn't seem correct:

output/build/ulog-0389d243352255f6182326dccdae3d56dadc078f/alchemy-out/staging/lib/libpthread.so:
ASCII text
output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/usr/lib/libpthread.so:                    
ASCII text
output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so:                         
ASCII text

They all contain:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )


On Fri, 2022-06-03 at 11:47 +0200, Thomas Petazzoni wrote:
> CAUTION: This email originated from outside of the organization.
> Do not click links or open attachments unless you recognize the sender and know the content is
> safe.
> 
> On Fri, 03 Jun 2022 11:09:48 +0200
> Nicolas Carrier <nicolas.carrier@orolia.com> wrote:
> 
> > Hello,
> > I tested this morning against the master of buildroot (with an ubuntu 20.04) and the issue
> > doesn't
> > appear anymore.
> > So there must be some change "recently" merged, which solves the issue.
> > 
> > An idea anyone?
> 
> Not yet an idea, but I confirm that I was able to reproduce on
> 2022.02.2 (just so you know that your e-mail and issue have been seen!)
> 
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering and training
> https://bootlin.com


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

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Nicolas Carrier]

And I redid the test with the working config (that is, without the SYSTEMD line) and this time there
are only:

output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/usr/lib/libpthread.so: ASCII text
output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so:      ASCII text

But their content is the same:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )


On Fri, 2022-06-03 at 12:44 +0200, Nicolas Carrier wrote:
> Great, at least, I'm not alone :)
> 
> One other thing to notice is that there libpthread.so ascii files in the output directory, the
> content of which doesn't seem correct:
> 
> output/build/ulog-0389d243352255f6182326dccdae3d56dadc078f/alchemy-out/staging/lib/libpthread.so:
> ASCII text
> output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/usr/lib/libpthread.so:                    
> ASCII text
> output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so:                         
> ASCII text
> 
> They all contain:
> 
> /* GNU ld script
>    Use the shared library, but some functions are only in
>    the static library, so try that secondarily.  */
> OUTPUT_FORMAT(elf32-littlearm)
> GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
> 
> 
> On Fri, 2022-06-03 at 11:47 +0200, Thomas Petazzoni wrote:
> > CAUTION: This email originated from outside of the organization.
> > Do not click links or open attachments unless you recognize the sender and know the content is
> > safe.
> > 
> > On Fri, 03 Jun 2022 11:09:48 +0200
> > Nicolas Carrier <nicolas.carrier@orolia.com> wrote:
> > 
> > > Hello,
> > > I tested this morning against the master of buildroot (with an ubuntu 20.04) and the issue
> > > doesn't
> > > appear anymore.
> > > So there must be some change "recently" merged, which solves the issue.
> > > 
> > > An idea anyone?
> > 
> > Not yet an idea, but I confirm that I was able to reproduce on
> > 2022.02.2 (just so you know that your e-mail and issue have been seen!)
> > 
> > Thomas
> > --
> > Thomas Petazzoni, co-owner and CEO, Bootlin
> > Embedded Linux and Kernel engineering and training
> > https://bootlin.com
> 
> 


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

Re: [Buildroot] ulog compilation issue with buildroot 2022.02.2

[Nicolas Carrier]

Shoot, apparently, I failed when testing yesterday.
The ulog build issue is present on master too, contrary to what I said earlier.

So now, we have no clue at all :/

On Fri, 2022-06-03 at 12:51 +0200, Nicolas Carrier wrote:
> And I redid the test with the working config (that is, without the SYSTEMD line) and this time
> there
> are only:
> 
> output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/usr/lib/libpthread.so: ASCII text
> output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so:      ASCII text
> 
> But their content is the same:
> 
> /* GNU ld script
>    Use the shared library, but some functions are only in
>    the static library, so try that secondarily.  */
> OUTPUT_FORMAT(elf32-littlearm)
> GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
> 
> 
> On Fri, 2022-06-03 at 12:44 +0200, Nicolas Carrier wrote:
> > Great, at least, I'm not alone :)
> > 
> > One other thing to notice is that there libpthread.so ascii files in the output directory, the
> > content of which doesn't seem correct:
> > 
> > output/build/ulog-0389d243352255f6182326dccdae3d56dadc078f/alchemy-
> > out/staging/lib/libpthread.so:
> > ASCII text
> > output/host/opt/ext-toolchain/arm-linux-gnueabihf/libc/usr/lib/libpthread.so:                   
> > ASCII text
> > output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libpthread.so:                        
> > ASCII text
> > 
> > They all contain:
> > 
> > /* GNU ld script
> >    Use the shared library, but some functions are only in
> >    the static library, so try that secondarily.  */
> > OUTPUT_FORMAT(elf32-littlearm)
> > GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )
> > 
> > 
> > On Fri, 2022-06-03 at 11:47 +0200, Thomas Petazzoni wrote:
> > > CAUTION: This email originated from outside of the organization.
> > > Do not click links or open attachments unless you recognize the sender and know the content is
> > > safe.
> > > 
> > > On Fri, 03 Jun 2022 11:09:48 +0200
> > > Nicolas Carrier <nicolas.carrier@orolia.com> wrote:
> > > 
> > > > Hello,
> > > > I tested this morning against the master of buildroot (with an ubuntu 20.04) and the issue
> > > > doesn't
> > > > appear anymore.
> > > > So there must be some change "recently" merged, which solves the issue.
> > > > 
> > > > An idea anyone?
> > > 
> > > Not yet an idea, but I confirm that I was able to reproduce on
> > > 2022.02.2 (just so you know that your e-mail and issue have been seen!)
> > > 
> > > Thomas
> > > --
> > > Thomas Petazzoni, co-owner and CEO, Bootlin
> > > Embedded Linux and Kernel engineering and training
> > > https://bootlin.com
> > 
> > 
> 


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