Skip to contentSkip to conversation

wireshark: remove RPATH tag

PATCH New Baruch Siach 5 participants 12 messages Nov 4, 2014 – Apr 5, 2015

lore
Share & tools
lore

Baruch Siach

author
#0 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Edit libtool to remove RPATH from generated binaries. This is similar to upstream commit making the same change when buiding RPMs.
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=a4a624e4c5

Signed-off-by Baruch Siach <[email protected]>
---
 package/wireshark/wireshark.mk | 6 ++++++
 1 file changed, 6 insertions(+)
package/wireshark/wireshark.mk +6 -0
index ccf5a56f1f23..6c7c3920e7af 100644
@@ -15,6 +15,12 @@ WIRESHARK_AUTORECONF = YES
 WIRESHARK_CONF_ENV = LIBGCRYPT_CONFIG=$(STAGING_DIR)/usr/bin/libgcrypt-config \
 			ac_cv_path_PCAP_CONFIG=$(STAGING_DIR)/usr/bin/pcap-config
 
+define WIRESHARK_REMOVE_RPATH
+	$(SED) 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' $(@D)/libtool
+	$(SED) 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' $(@D)/libtool
+endef
+WIRESHARK_POST_CONFIGURE_HOOKS += WIRESHARK_REMOVE_RPATH
+
 # wireshark adds -I$includedir to CFLAGS, causing host/target headers mixup.
 # Work around it by pointing includedir at staging
 WIRESHARK_CONF_OPTS = --disable-wireshark --without-krb5 --disable-usr-local \
Signature · 1 line
2.1.1
#1 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Dear Baruch Siach,

Quoted 14 lines · Baruch Siach

Edit libtool to remove RPATH from generated binaries. This is similar to upstream commit making the same change when buiding RPMs.
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=a4a624e4c5

Signed-off-by Baruch Siach <[email protected]>
---
 package/wireshark/wireshark.mk | 6 ++++++
 1 file changed, 6 insertions(+)
package/wireshark/wireshark.mk +0 -0
index ccf5a56f1f23..6c7c3920e7af 100644

package/wireshark/wireshark.mk WIRESHARK_AUTORECONF = YES · line 22

Quoted 8 lines
package/wireshark/wireshark.mk +5 -0
@@ -15,6 +15,12 @@ WIRESHARK_AUTORECONF = YES
 WIRESHARK_CONF_ENV = LIBGCRYPT_CONFIG=$(STAGING_DIR)/usr/bin/libgcrypt-config \
 			ac_cv_path_PCAP_CONFIG=$(STAGING_DIR)/usr/bin/pcap-config
 
+define WIRESHARK_REMOVE_RPATH
+	$(SED) 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' $(@D)/libtool
+	$(SED) 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' $(@D)/libtool
+endef
+WIRESHARK_POST_CONFIGURE_HOOKS += WIRESHARK_REMOVE_RPATH

Isn't this problem potentially identical in many packages that use libtool? What leads the wireshark libtool to have this specifically?

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#2 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Hi Thomas,

Quoted 18 lines · Thomas Petazzoni
Quoted 17 lines · Baruch Siach

Edit libtool to remove RPATH from generated binaries. This is similar to upstream commit making the same change when buiding RPMs.
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=a4a624e4c5

Signed-off-by Baruch Siach <[email protected]>
---
 package/wireshark/wireshark.mk | 6 ++++++
 1 file changed, 6 insertions(+)
package/wireshark/wireshark.mk +0 -0
index ccf5a56f1f23..6c7c3920e7af 100644
@@ -15,6 +15,12 @@ WIRESHARK_AUTORECONF = YES
 WIRESHARK_CONF_ENV = LIBGCRYPT_CONFIG=$(STAGING_DIR)/usr/bin/libgcrypt-config \
 			ac_cv_path_PCAP_CONFIG=$(STAGING_DIR)/usr/bin/pcap-config
Quoted 8 lines

package/wireshark/wireshark.mk WIRESHARK_AUTORECONF = YES · line 22

Quoted 5 lines
package/wireshark/wireshark.mk +5 -0
+define WIRESHARK_REMOVE_RPATH
+	$(SED) 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' $(@D)/libtool
+	$(SED) 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' $(@D)/libtool
+endef
+WIRESHARK_POST_CONFIGURE_HOOKS += WIRESHARK_REMOVE_RPATH

Isn't this problem potentially identical in many packages that use libtool? What leads the wireshark libtool to have this specifically?

Probably. The Buildorot speex package does an almost identical edit to its own libtool. Do you think we should enable this for all libtool users? We'll only know if anything breaks at run time.

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#3 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Dear Baruch Siach,

Quoted 6 lines · Baruch Siach
Quoted 2 lines

Isn't this problem potentially identical in many packages that use libtool? What leads the wireshark libtool to have this specifically?

Probably. The Buildorot speex package does an almost identical edit to its own libtool. Do you think we should enable this for all libtool users? We'll only know if anything breaks at run time.

Well, not having a rpath should not break things at runtime, unless a custom rpath is really necessary. But I'm pretty sure in those cases, the custom rpath will be wrong as it will point to some location on the build machine.

What would be good is to understand why in certain situations libtool decides to set a rpath and not in other cases.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#4 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Hi Thomas,

Quoted 9 lines · Thomas Petazzoni
Quoted 6 lines · Baruch Siach
Quoted 2 lines

Isn't this problem potentially identical in many packages that use libtool? What leads the wireshark libtool to have this specifically?

Probably. The Buildorot speex package does an almost identical edit to its own libtool. Do you think we should enable this for all libtool users? We'll only know if anything breaks at run time.

Quoted 7 lines

Well, not having a rpath should not break things at runtime, unless a custom rpath is really necessary. But I'm pretty sure in those cases, the custom rpath will be wrong as it will point to some location on the build machine.

What would be good is to understand why in certain situations libtool decides to set a rpath and not in other cases.

It seems that libtool decides to set rpath based on .la files we have in staging. Some of them (e.g. glib provided libs, and libnl) set either 'dependency_libs' (glib) or 'libdir' (libnl) to paths under output/build or staging. wireshark also links its own libraries (e.g. wiretap, epan) using local source tree .la files. I'm not sure how to solve this in the general case. It probably requires fixing up all these .la files.

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#5 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Quoted 6 lines · Baruch Siach

It seems that libtool decides to set rpath based on .la files we have in staging. Some of them (e.g. glib provided libs, and libnl) set either 'dependency_libs' (glib) or 'libdir' (libnl) to paths under output/build or staging. wireshark also links its own libraries (e.g. wiretap, epan) using local source tree .la files. I'm not sure how to solve this in the general case. It probably requires fixing up all these .la files.

Hi.
There's a good briefing at https://wiki.debian.org/RpathIssue
Fixing up is nice, however doing it in a good manner will require many autoreconfs and being proactive about it.
Stripping RPATHs is probably a faster way out (via chrpath). In the end this could be considered as a build information leak, not terribly useful but doesn't look good either.
Regards.

#6 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Quoted 8 lines · Gustavo Zacarias
Quoted 6 lines · Baruch Siach

It seems that libtool decides to set rpath based on .la files we have in staging. Some of them (e.g. glib provided libs, and libnl) set either 'dependency_libs' (glib) or 'libdir' (libnl) to paths under output/build or staging. wireshark also links its own libraries (e.g. wiretap, epan) using local source tree .la files. I'm not sure how to solve this in the general case. It probably requires fixing up all these .la files.

The weird thing is that not all autotools packages have a rpath... :-/ I've already try to have a look at libtool, but it requires quite a brain at 300% and some free time to dive into this hell.

Quoted 6 lines

Hi.
There's a good briefing at https://wiki.debian.org/RpathIssue
Fixing up is nice, however doing it in a good manner will require many autoreconfs and being proactive about it.
Stripping RPATHs is probably a faster way out (via chrpath).

or patchelf (already in buildroot) ;-)

Quoted 8 lines

In the end this could be considered as a build information leak, not terribly useful but doesn't look good either.
Regards.

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Regards,

Signature · 1 line
Samuel
author
#7 lore raw

PATCH 1/1 wireshark: remove RPATH tag

In reply to Gustavo Zacarias

Hi Gustavo,

Quoted 8 lines · Gustavo Zacarias
Quoted 6 lines · Baruch Siach

It seems that libtool decides to set rpath based on .la files we have in staging. Some of them (e.g. glib provided libs, and libnl) set either 'dependency_libs' (glib) or 'libdir' (libnl) to paths under output/build or staging. wireshark also links its own libraries (e.g. wiretap, epan) using local source tree .la files. I'm not sure how to solve this in the general case. It probably requires fixing up all these .la files.

Quoted 6 lines

There's a good briefing at https://wiki.debian.org/RpathIssue
Fixing up is nice, however doing it in a good manner will require many autoreconfs and being proactive about it.
Stripping RPATHs is probably a faster way out (via chrpath). In the end this could be considered as a build information leak, not terribly useful but doesn't look good either.

chrpath can indeed nullify the ELF RPATH tag, but it leaves the ELF string table alone. This means that the build paths information leak is still there, though somewhat less noticeable.

Until we find a better solution I think this patch can go in for -next.

baruch

Signature · 3 lines
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
#8 lore raw

PATCH 1/1 wireshark: remove RPATH tag

In reply to Baruch Siach

Dear Baruch Siach,

Quoted 8 lines · Baruch Siach

Edit libtool to remove RPATH from generated binaries. This is similar to upstream commit making the same change when buiding RPMs.
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=a4a624e4c5

Signed-off-by Baruch Siach <[email protected]>
---
 package/wireshark/wireshark.mk | 6 ++++++
 1 file changed, 6 insertions(+)

I'm still not sure what to do with this. Yann, Gustavo, Samuel, some suggestions ?

Should we introduce a final check in target-finalize to warn about binaries having invalid rpaths, and start fixing them one by one ? Or a more brutal approach where we remove all rpaths in target-finalize ?

I'm a bit uncomfortable with having a fix for just one package without having a globally defined policy on how to handle this rpath mess. Opinions welcome.

Thanks,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#9 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Thomas, All,

On 2015-04-04 19:59 +0200, Thomas Petazzoni spake thusly:

Quoted 10 lines · Baruch Siach
Quoted 8 lines

Edit libtool to remove RPATH from generated binaries. This is similar to upstream commit making the same change when buiding RPMs.
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=a4a624e4c5

Signed-off-by Baruch Siach <[email protected]>
---
 package/wireshark/wireshark.mk | 6 ++++++
 1 file changed, 6 insertions(+)
Quoted 6 lines

I'm still not sure what to do with this. Yann, Gustavo, Samuel, some suggestions ?

Should we introduce a final check in target-finalize to warn about binaries having invalid rpaths, and start fixing them one by one ? Or a more brutal approach where we remove all rpaths in target-finalize ?

I have a series doing exactly that; I'll be sending it shortly.

Quoted 3 lines

I'm a bit uncomfortable with having a fix for just one package without having a globally defined policy on how to handle this rpath mess. Opinions welcome.

I feel the same.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#10 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Dear Yann E. MORIN,

Quoted 5 lines · Yann E. MORIN
Quoted 3 lines

Should we introduce a final check in target-finalize to warn about binaries having invalid rpaths, and start fixing them one by one ? Or a more brutal approach where we remove all rpaths in target-finalize ?

I have a series doing exactly that; I'll be sending it shortly.

There was some concern in this thread that the approach to remove the rpath at the end of the build was indeed making the built-in rpath ineffective, but still present if you did a "strings" on the binary. Is this something you have a solution for?

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#11 lore raw

PATCH 1/1 wireshark: remove RPATH tag

Thomas, All,

On 2015-04-05 11:29 +0200, Thomas Petazzoni spake thusly:

Quoted 11 lines · Yann E. MORIN
Quoted 5 lines
Quoted 3 lines

Should we introduce a final check in target-finalize to warn about binaries having invalid rpaths, and start fixing them one by one ? Or a more brutal approach where we remove all rpaths in target-finalize ?

I have a series doing exactly that; I'll be sending it shortly.

There was some concern in this thread that the approach to remove the rpath at the end of the build was indeed making the built-in rpath ineffective, but still present if you did a "strings" on the binary. Is this something you have a solution for?

Hmm... What I do is use patch-e;f to remove it altogether, yes.

Now, if there is another reference to it in another section (e.g. .data or .rodata) I don't know. I can do a biggish test-build with lotta packages and do a string on there, but I'm afraid we will find it in those data sections, if only because some tools store the build dir and some other things in there.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'