All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Buildroot] package gdk-pixbuf relocatable issue
@ 2022-03-17 13:19 Sassen, Rutger
  2022-03-17 13:35 ` Fabrice Fontaine
  0 siblings, 1 reply; 5+ messages in thread
From: Sassen, Rutger @ 2022-03-17 13:19 UTC (permalink / raw)
  To: Fabrice Fontaine; +Cc: buildroot


[-- Attachment #1.1: Type: text/plain, Size: 1996 bytes --]

Hello Fabrice,

> > A recent patch for package gdk-pixbuf to enable the relocatable option for the host package has introduced a problem for the target package.
>
> > The loaders.cache for the target currently is generated by copying the loaders.cache from the host package and editing it using a sed command to replace the host paths with target paths. The sed command is no longer correct, since the host loaders.cache does not contain absolute paths anymore.
> >
> > The consequence is, that the target loaders.cache now contains entries like "lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*". These paths are incorrect, and applications using gdk-pixbuf will crash because they are no longer able to load images. Before the patch, it would contain absolute paths like "/usr/lib/gdk-pixbuf-> 2.0/2.10.0/loaders/libpixbufloader-*".
> >
> > I'm not sure what the best approach would be to fix this issue. Either by modifying the SED statement, or by modifying the way the target loaders.cache is generated (i.e. by not using the host loaders.cache as a base).
>
> Thanks for spotting this issue, I think the best approach is to:
> - set relocatable to true for the target (see
> https://patchwork.ozlabs.org/project/buildroot/patch/20220219122526.2954354-1-fontaine.fabrice@gmail.com)
> - drop GDK_PIXBUF_UPDATE_CACHE (which has no effect anymore)
>
> Can you confirm that this approach is working?

Unfortunately this is not working. Without the GDK_PIXBUF_UPDATE_CACHE, the target ends up with no loaders.cache at all.
It’s also not possible to run gdk-pixbuf-query-loaders in the target directory because the architecture might differ from the host.

Best regards,

Rutger

This email communication is CONFIDENTIAL. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message and I ask that you please notify me by return email and delete this communication immediately. Thank you.

[-- Attachment #1.2: Type: text/html, Size: 2578 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Buildroot] package gdk-pixbuf relocatable issue
  2022-03-17 13:19 [Buildroot] package gdk-pixbuf relocatable issue Sassen, Rutger
@ 2022-03-17 13:35 ` Fabrice Fontaine
  0 siblings, 0 replies; 5+ messages in thread
From: Fabrice Fontaine @ 2022-03-17 13:35 UTC (permalink / raw)
  To: Sassen, Rutger; +Cc: buildroot

Le jeu. 17 mars 2022 à 14:19, Sassen, Rutger <rsassen@comecer.com> a écrit :
>
> Hello Fabrice,
>
> > > A recent patch for package gdk-pixbuf to enable the relocatable option for the host package has introduced a problem for the target package.
> >
> > > The loaders.cache for the target currently is generated by copying the loaders.cache from the host package and editing it using a sed command to replace the host paths with target paths. The sed command is no longer correct, since the host loaders.cache does not contain absolute paths anymore.
> > >
> > > The consequence is, that the target loaders.cache now contains entries like "lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*". These paths are incorrect, and applications using gdk-pixbuf will crash because they are no longer able to load images. Before the patch, it would contain absolute paths like "/usr/lib/gdk-pixbuf-> 2.0/2.10.0/loaders/libpixbufloader-*".
> > >
> > > I'm not sure what the best approach would be to fix this issue. Either by modifying the SED statement, or by modifying the way the target loaders.cache is generated (i.e. by not using the host loaders.cache as a base).
> >
> > Thanks for spotting this issue, I think the best approach is to:
> > - set relocatable to true for the target (see
> > https://patchwork.ozlabs.org/project/buildroot/patch/20220219122526.2954354-1-fontaine.fabrice@gmail.com)
> > - drop GDK_PIXBUF_UPDATE_CACHE (which has no effect anymore)
> >
> > Can you confirm that this approach is working?
>
> Unfortunately this is not working. Without the GDK_PIXBUF_UPDATE_CACHE, the target ends up with no loaders.cache at all.
Indeed, good catch, then we can only drop the SED command.

However, can you confirm that setting relocatable to true doesn't fix the issue?
From my understanding, if relocatable is true, gdk-pixbuf should
prepend the toplevel dir:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/blob/master/gdk-pixbuf/gdk-pixbuf-io.c#L352

If this doesn't work (because the toplevel dir is not correct), then
the better option would be to update the SED command to prepend /usr/
to all lib paths.
> It’s also not possible to run gdk-pixbuf-query-loaders in the target directory because the architecture might differ from the host.
>
> Best regards,
>
> Rutger
>
>
> Disclaimer
>
> This email communication is CONFIDENTIAL. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message and I ask that you please notify me by return email and delete this communication immediately. Thank you.
Best Regards,

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Buildroot] package gdk-pixbuf relocatable issue
@ 2022-03-17 15:28 Sassen, Rutger
  0 siblings, 0 replies; 5+ messages in thread
From: Sassen, Rutger @ 2022-03-17 15:28 UTC (permalink / raw)
  To: Fabrice Fontaine; +Cc: buildroot


[-- Attachment #1.1: Type: text/plain, Size: 2631 bytes --]

> > > > A recent patch for package gdk-pixbuf to enable the relocatable option for the host package has introduced a problem for the target package.
> > >
> > > > The loaders.cache for the target currently is generated by copying the loaders.cache from the host package and editing it using a sed command to replace the host paths with target paths. The sed command is no longer correct, since the host loaders.cache does not contain absolute paths anymore.
> > > >
> > > > The consequence is, that the target loaders.cache now contains entries like "lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*". These paths are incorrect, and applications using gdk-pixbuf will crash because they are no longer able to load images. Before the patch, it would contain absolute paths like "/usr/lib/gdk-pixbuf-
> > 2.0/2.10.0/loaders/libpixbufloader-*".
> > > >
> > > > I'm not sure what the best approach would be to fix this issue. Either by modifying the SED statement, or by modifying the way the target loaders.cache is generated (i.e. by not using the host loaders.cache as a base).
> > >
> > > Thanks for spotting this issue, I think the best approach is to:
> > > - set relocatable to true for the target (see
> > > https://patchwork.ozlabs.org/project/buildroot/patch/20220219122526.2954354-1-fontaine.fabrice@gmail.com)
> > > - drop GDK_PIXBUF_UPDATE_CACHE (which has no effect anymore)
> > >
> > > Can you confirm that this approach is working?
> >
> > Unfortunately this is not working. Without the GDK_PIXBUF_UPDATE_CACHE, the target ends up with no loaders.cache at all.
> Indeed, good catch, then we can only drop the SED command.

> However, can you confirm that setting relocatable to true doesn't fix the issue?
> From my understanding, if relocatable is true, gdk-pixbuf should
> prepend the toplevel dir:
> https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/blob/master/gdk-pixbuf/gdk-pixbuf-io.c#L352

It tested it, and it does not work.
From my understanding this toplevel dir is one directory up relative to the path of the executable,
so if the executable is /foo/bar/my_executable , the toplevel dir will be /foo .

> If this doesn't work (because the toplevel dir is not correct), then
> the better option would be to update the SED command to prepend /usr/
> to all lib paths.

I agree.

Rutger

This email communication is CONFIDENTIAL. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message and I ask that you please notify me by return email and delete this communication immediately. Thank you.

[-- Attachment #1.2: Type: text/html, Size: 3502 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Buildroot] package gdk-pixbuf relocatable issue
  2022-03-16 11:09 Sassen, Rutger
@ 2022-03-17 10:06 ` Fabrice Fontaine
  0 siblings, 0 replies; 5+ messages in thread
From: Fabrice Fontaine @ 2022-03-17 10:06 UTC (permalink / raw)
  To: Sassen, Rutger; +Cc: buildroot

Hello,

Le mer. 16 mars 2022 à 12:09, Sassen, Rutger <rsassen@comecer.com> a écrit :
>
> Hello,
>
> A recent patch for package gdk-pixbuf to enable the relocatable option for the host package has introduced a problem for the target package.
>
> The loaders.cache for the target currently is generated by copying the loaders.cache from the host package and editing it using a sed command to replace the host paths with target paths. The sed command is no longer correct, since the host loaders.cache does not contain absolute paths anymore.
>
> The consequence is, that the target loaders.cache now contains entries like "lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*". These paths are incorrect, and applications using gdk-pixbuf will crash because they are no longer able to load images. Before the patch, it would contain absolute paths like "/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*".
>
> I'm not sure what the best approach would be to fix this issue. Either by modifying the SED statement, or by modifying the way the target loaders.cache is generated (i.e. by not using the host loaders.cache as a base).

Thanks for spotting this issue, I think the best approach is to:
 - set relocatable to true for the target (see
https://patchwork.ozlabs.org/project/buildroot/patch/20220219122526.2954354-1-fontaine.fabrice@gmail.com)
 - drop GDK_PIXBUF_UPDATE_CACHE (which has no effect anymore)

Can you confirm that this approach is working?
In this case, can you send a patch to the mailing list?
>
> My configuration:
> Host: Debian 10 (buster)
> Buildroot version: 2022-02
> Target: Aarch64 (raspberry pi cm3)
> Package: gdk-pixbuf
>
> The problematic snippets from gdk-pixbuf.mk:
>
> ==============
> HOST_GDK_PIXBUF_CONF_OPTS = \
> -Dgio_sniffing=false \
> -Dinstalled_tests=false \
> -Dintrospection=disabled \
> -Drelocatable=true \
> -Dman=false
> ==============
> # gdk-pixbuf requires the loaders.cache file populated to work properly
> # Rather than doing so at runtime, since the fs can be read-only, do so
> # here after building and installing to target.
> # And since the cache file will contain absolute host directory names we
> # need to sanitize (strip) them.
> ifeq ($(BR2_STATIC_LIBS),)
> define GDK_PIXBUF_UPDATE_CACHE
> GDK_PIXBUF_MODULEDIR=$(HOST_DIR)/lib/gdk-pixbuf-2.0/2.10.0/loaders \
> $(HOST_DIR)/bin/gdk-pixbuf-query-loaders \
> > $(TARGET_DIR)/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
> $(SED) "s,$(HOST_DIR)/lib,/usr/lib,g" \
> $(TARGET_DIR)/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
> endef
> GDK_PIXBUF_POST_INSTALL_TARGET_HOOKS += GDK_PIXBUF_UPDATE_CACHE
> endif
> ==============
>
> Best regards,
>
> Rutger Sassen
>
> p.s. please ignore the email disclaimer that is automatically added to all my outgoing mail...
>
>
> Disclaimer
>
> This email communication is CONFIDENTIAL. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message and I ask that you please notify me by return email and delete this communication immediately. Thank you.

Best Regards,

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] package gdk-pixbuf relocatable issue
@ 2022-03-16 11:09 Sassen, Rutger
  2022-03-17 10:06 ` Fabrice Fontaine
  0 siblings, 1 reply; 5+ messages in thread
From: Sassen, Rutger @ 2022-03-16 11:09 UTC (permalink / raw)
  To: buildroot; +Cc: Fabrice Fontaine


[-- Attachment #1.1: Type: text/plain, Size: 2568 bytes --]

Hello,

A recent patch for package gdk-pixbuf to enable the relocatable option for the host package has introduced a problem for the target package.

The loaders.cache for the target currently is generated by copying the loaders.cache from the host package and editing it using a sed command to replace the host paths with target paths. The sed command is no longer correct, since the host loaders.cache does not contain absolute paths anymore.

The consequence is, that the target loaders.cache now contains entries like "lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*". These paths are incorrect, and applications using gdk-pixbuf will crash because they are no longer able to load images. Before the patch, it would contain absolute paths like "/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-*".

I'm not sure what the best approach would be to fix this issue. Either by modifying the SED statement, or by modifying the way the target loaders.cache is generated (i.e. by not using the host loaders.cache as a base).

My configuration:
Host: Debian 10 (buster)
Buildroot version: 2022-02
Target: Aarch64 (raspberry pi cm3)
Package: gdk-pixbuf

The problematic snippets from gdk-pixbuf.mk:

==============
HOST_GDK_PIXBUF_CONF_OPTS = \
	-Dgio_sniffing=false \
	-Dinstalled_tests=false \
	-Dintrospection=disabled \
	-Drelocatable=true \
	-Dman=false
==============
# gdk-pixbuf requires the loaders.cache file populated to work properly
# Rather than doing so at runtime, since the fs can be read-only, do so
# here after building and installing to target.
# And since the cache file will contain absolute host directory names we
# need to sanitize (strip) them.
ifeq ($(BR2_STATIC_LIBS),)
define GDK_PIXBUF_UPDATE_CACHE
	GDK_PIXBUF_MODULEDIR=$(HOST_DIR)/lib/gdk-pixbuf-2.0/2.10.0/loaders \
		$(HOST_DIR)/bin/gdk-pixbuf-query-loaders \
		> $(TARGET_DIR)/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
	$(SED) "s,$(HOST_DIR)/lib,/usr/lib,g" \
		$(TARGET_DIR)/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
endef
GDK_PIXBUF_POST_INSTALL_TARGET_HOOKS += GDK_PIXBUF_UPDATE_CACHE
endif
==============

Best regards,

Rutger Sassen

p.s. please ignore the email disclaimer that is automatically added to all my outgoing mail...

This email communication is CONFIDENTIAL. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message and I ask that you please notify me by return email and delete this communication immediately. Thank you.

[-- Attachment #1.2: Type: text/html, Size: 3064 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-03-17 15:28 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-17 13:19 [Buildroot] package gdk-pixbuf relocatable issue Sassen, Rutger
2022-03-17 13:35 ` Fabrice Fontaine
  -- strict thread matches above, loose matches on Subject: below --
2022-03-17 15:28 Sassen, Rutger
2022-03-16 11:09 Sassen, Rutger
2022-03-17 10:06 ` Fabrice Fontaine

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.