| Message ID | 20190528203230.24558-1-fontaine.fabrice@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/1] package/wireshark: fix static build with snappy | expand |
Hello, On Tue, 28 May 2019 22:32:30 +0200 Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: > Fixes: > - http://autobuild.buildroot.org/results/419468f0d7d3c2b64d420513aa9505c6de097ed2 > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > --- > Changes v1 -> v2 (after review of Arnout Vandecappelle): > - Set linker to CXX instead of adding -lstdc++ to LIBS Is this really the right thing to do? Ideally a program written in C should not have to know that a library it is using is written in C++. We already had a similar situation in Buildroot, and so far we have added -lstdc++. For example: ifeq ($(BR2_PACKAGE_DIRECTFB),y) LINKS_CONF_ENV = ac_cv_path_DIRECTFB_CONFIG=$(STAGING_DIR)/usr/bin/directfb-config ifeq ($(BR2_STATIC_LIBS),y) LINKS_CONF_ENV += LIBS=-lstdc++ and there's a few other examples in the tree. To be honest, I don't know what is the most correct solution, I'm just trying to make sure we solve a given problem in the same way everywhere. Best regards, Thomas
Dear Thomas and Arnout, Le mar. 28 mai 2019 à 22:42, Thomas Petazzoni <thomas.petazzoni@bootlin.com> a écrit : > > Hello, > > On Tue, 28 May 2019 22:32:30 +0200 > Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: > > > Fixes: > > - http://autobuild.buildroot.org/results/419468f0d7d3c2b64d420513aa9505c6de097ed2 > > > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > > --- > > Changes v1 -> v2 (after review of Arnout Vandecappelle): > > - Set linker to CXX instead of adding -lstdc++ to LIBS > > Is this really the right thing to do? Ideally a program written in C > should not have to know that a library it is using is written in C++. > > We already had a similar situation in Buildroot, and so far we have > added -lstdc++. For example: > > ifeq ($(BR2_PACKAGE_DIRECTFB),y) > LINKS_CONF_ENV = ac_cv_path_DIRECTFB_CONFIG=$(STAGING_DIR)/usr/bin/directfb-config > ifeq ($(BR2_STATIC_LIBS),y) > LINKS_CONF_ENV += LIBS=-lstdc++ > > and there's a few other examples in the tree. To be honest, I don't > know what is the most correct solution, I'm just trying to make sure we > solve a given problem in the same way everywhere. I don't know either. You can apply the first or the second version of this patch. Then, I'll send the chosen version upstream. If they don't like it, I'll have the second solution as a fallback. > > Best regards, > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Best Regards, Fabrice
On 28/05/2019 22:48, Fabrice Fontaine wrote: > Dear Thomas and Arnout, > > Le mar. 28 mai 2019 à 22:42, Thomas Petazzoni > <thomas.petazzoni@bootlin.com> a écrit : >> >> Hello, >> >> On Tue, 28 May 2019 22:32:30 +0200 >> Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote: >> >>> Fixes: >>> - http://autobuild.buildroot.org/results/419468f0d7d3c2b64d420513aa9505c6de097ed2 >>> >>> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> >>> --- >>> Changes v1 -> v2 (after review of Arnout Vandecappelle): >>> - Set linker to CXX instead of adding -lstdc++ to LIBS >> >> Is this really the right thing to do? Ideally a program written in C >> should not have to know that a library it is using is written in C++. Hm, good point... Snappy provides a C wrapper, so there should indeed not be a need for the client to use the C++ linker. Of course, there also shouldn't be a need for the client to link with libstdc++ :-). I guess ideally Snappy would somehow include the libstdc++ link in its EXPORT directive, but I have no idea how to achieve that... >> We already had a similar situation in Buildroot, and so far we have >> added -lstdc++. For example: >> >> ifeq ($(BR2_PACKAGE_DIRECTFB),y) >> LINKS_CONF_ENV = ac_cv_path_DIRECTFB_CONFIG=$(STAGING_DIR)/usr/bin/directfb-config >> ifeq ($(BR2_STATIC_LIBS),y) >> LINKS_CONF_ENV += LIBS=-lstdc++ >> >> and there's a few other examples in the tree. To be honest, I don't >> know what is the most correct solution, I'm just trying to make sure we >> solve a given problem in the same way everywhere. In most other cases we don't do any patching but we pass it through LIBS or similar. I don't think that that's possible with CMake. For ICU, we patch the .pc file, which is the proper thing to do, but Snappy doesn't have a .pc file. The only one where we do it with patching is xvkbd, but there we create the entire (generated) Makefile so it doesn't count. But yeah, in keeping with the 'add -lstdc++' principle, and because the patch is smaller, maybe v1 was better. > I don't know either. You can apply the first or the second version of > this patch. I reset its state to New. Now Thomas can decide :-) > Then, I'll send the chosen version upstream. If they don't like it, > I'll have the second solution as a fallback. Maybe just send both versions upstream, since you have them both now. Then they can choose which one they like better. Regards, Arnout
Hello, On Tue, 28 May 2019 23:04:28 +0200 Arnout Vandecappelle <arnout@mind.be> wrote: > >> Is this really the right thing to do? Ideally a program written in C > >> should not have to know that a library it is using is written in C++. > > Hm, good point... Snappy provides a C wrapper, so there should indeed not be a > need for the client to use the C++ linker. Of course, there also shouldn't be a > need for the client to link with libstdc++ :-). There is no need to link with libstdc++ when dynamic linking is used, which to me is another indication that using the C++ linker is not the right approach. Adding -lstdc++ is only necessary in static linking configuration, for the usual reason that libA -> libB -> libC in static linking scenarios requires passing -lC when linking libA. > >> and there's a few other examples in the tree. To be honest, I don't > >> know what is the most correct solution, I'm just trying to make > >> sure we solve a given problem in the same way everywhere. > > In most other cases we don't do any patching but we pass it through > LIBS or similar. I don't think that that's possible with CMake. > > For ICU, we patch the .pc file, which is the proper thing to do, but > Snappy doesn't have a .pc file. Yes, but to me that's another indication that the right thing to do is to pass -lstdc++: if the packages were better, they would be using .pc files, and we would be able to specify -lstdc++ in their Libs.private. Once again, it shows that using the C++ linker is (to me) not the right approach. > > I don't know either. You can apply the first or the second version > > of this patch. > > I reset its state to New. Now Thomas can decide :-) For the reasons stated above, I think I prefer v1. > Maybe just send both versions upstream, since you have them both > now. Then they can choose which one they like better. The most correct solution for upstream would be for snappy to provide a .pc file, and for wireshark to use it. Best regards, Thomas
On 29/05/2019 08:53, Thomas Petazzoni wrote: > Hello, > > On Tue, 28 May 2019 23:04:28 +0200 > Arnout Vandecappelle <arnout@mind.be> wrote: > >>>> Is this really the right thing to do? Ideally a program written in C >>>> should not have to know that a library it is using is written in C++. >> >> Hm, good point... Snappy provides a C wrapper, so there should indeed not be a >> need for the client to use the C++ linker. Of course, there also shouldn't be a >> need for the client to link with libstdc++ :-). > > There is no need to link with libstdc++ when dynamic linking is used, > which to me is another indication that using the C++ linker is not the > right approach. Adding -lstdc++ is only necessary in static linking > configuration, for the usual reason that libA -> libB -> libC in static > linking scenarios requires passing -lC when linking libA. > >>>> and there's a few other examples in the tree. To be honest, I don't >>>> know what is the most correct solution, I'm just trying to make >>>> sure we solve a given problem in the same way everywhere. >> >> In most other cases we don't do any patching but we pass it through >> LIBS or similar. I don't think that that's possible with CMake. >> >> For ICU, we patch the .pc file, which is the proper thing to do, but >> Snappy doesn't have a .pc file. > > Yes, but to me that's another indication that the right thing to do is > to pass -lstdc++: if the packages were better, they would be using .pc > files, and we would be able to specify -lstdc++ in their Libs.private. > Once again, it shows that using the C++ linker is (to me) not the right > approach. +1. >>> I don't know either. You can apply the first or the second version >>> of this patch. >> >> I reset its state to New. Now Thomas can decide :-) > > For the reasons stated above, I think I prefer v1. +1 >> Maybe just send both versions upstream, since you have them both >> now. Then they can choose which one they like better. > > The most correct solution for upstream would be for snappy to provide > a .pc file, and for wireshark to use it. Not really. Both Snappy and wireshark are CMake packages, so even if Snappy would install a .pc file, wireshark wouldn't use it because the CMake infra is preferred. The real solution is that CMake has an equivalent of Libs.private, and that Snappy populates it. But my CMake-fu is not up to this task I'm afraid. Well, I suppose I *could* find out, but I don't have the time for it :-) Any CMake experts on the list? Regards, Arnout
Dear all, Le mer. 29 mai 2019 à 10:49, Arnout Vandecappelle <arnout@mind.be> a écrit : > > > > On 29/05/2019 08:53, Thomas Petazzoni wrote: > > Hello, > > > > On Tue, 28 May 2019 23:04:28 +0200 > > Arnout Vandecappelle <arnout@mind.be> wrote: > > > >>>> Is this really the right thing to do? Ideally a program written in C > >>>> should not have to know that a library it is using is written in C++. > >> > >> Hm, good point... Snappy provides a C wrapper, so there should indeed not be a > >> need for the client to use the C++ linker. Of course, there also shouldn't be a > >> need for the client to link with libstdc++ :-). > > > > There is no need to link with libstdc++ when dynamic linking is used, > > which to me is another indication that using the C++ linker is not the > > right approach. Adding -lstdc++ is only necessary in static linking > > configuration, for the usual reason that libA -> libB -> libC in static > > linking scenarios requires passing -lC when linking libA. > > > >>>> and there's a few other examples in the tree. To be honest, I don't > >>>> know what is the most correct solution, I'm just trying to make > >>>> sure we solve a given problem in the same way everywhere. > >> > >> In most other cases we don't do any patching but we pass it through > >> LIBS or similar. I don't think that that's possible with CMake. > >> > >> For ICU, we patch the .pc file, which is the proper thing to do, but > >> Snappy doesn't have a .pc file. Actually, former versions of snappy had a .pc file. A PR is opened since 2017 to readd it: https://github.com/google/snappy/pull/51. It seems there was some activities on this PR in the last few days so I hope it will get merged. I'll send a patch to add it to buildroot (with Libs.private). > > > > Yes, but to me that's another indication that the right thing to do is > > to pass -lstdc++: if the packages were better, they would be using .pc > > files, and we would be able to specify -lstdc++ in their Libs.private. > > Once again, it shows that using the C++ linker is (to me) not the right > > approach. > > +1. > > > >>> I don't know either. You can apply the first or the second version > >>> of this patch. > >> > >> I reset its state to New. Now Thomas can decide :-) > > > > For the reasons stated above, I think I prefer v1. > > +1 > > > >> Maybe just send both versions upstream, since you have them both > >> now. Then they can choose which one they like better. > > > > The most correct solution for upstream would be for snappy to provide > > a .pc file, and for wireshark to use it. > > Not really. Both Snappy and wireshark are CMake packages, so even if Snappy > would install a .pc file, wireshark wouldn't use it because the CMake infra is > preferred. > > The real solution is that CMake has an equivalent of Libs.private, and that > Snappy populates it. But my CMake-fu is not up to this task I'm afraid. Well, I > suppose I *could* find out, but I don't have the time for it :-) > > Any CMake experts on the list? Actually, wireshark is already using pkg-config inside cmake to find most of his libraries, including snappy: if( NOT WIN32) find_package(PkgConfig) pkg_search_module(SNAPPY libsnappy) endif() However, as usual, they don't forward those dependencies and override SNAPPY_LIBRARIES by SNAPPY_LIBRARY. I'll fix it and a send a patch upstream to wireshark. > > Regards, > Arnout Best Regards, Fabrice
Fabrice, All, On 2019-05-28 22:32 +0200, Fabrice Fontaine spake thusly: > Fixes: > - http://autobuild.buildroot.org/results/419468f0d7d3c2b64d420513aa9505c6de097ed2 > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> I had been contemplating that patch for quite some time now, and was really undecided what we were to be doing about it... But now, we've accepted your patch to make woreshark depend on shared libraries, so this build failure should no longer occur any more, or so I hope. Marked as "not applicable" in Patchwork. Thank you! Regards, Yann E. MORIN. > --- > Changes v1 -> v2 (after review of Arnout Vandecappelle): > - Set linker to CXX instead of adding -lstdc++ to LIBS > > ...s.txt-fix-static-linking-with-snappy.patch | 98 +++++++++++++++++++ > 1 file changed, 98 insertions(+) > create mode 100644 package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch > > diff --git a/package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch b/package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch > new file mode 100644 > index 0000000000..e9233aa90f > --- /dev/null > +++ b/package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch > @@ -0,0 +1,98 @@ > +From eb226af7ae998cda6b9747d9e77692fda85563bc Mon Sep 17 00:00:00 2001 > +From: Fabrice Fontaine <fontaine.fabrice@gmail.com> > +Date: Tue, 28 May 2019 21:26:19 +0200 > +Subject: [PATCH] CMakeLists.txt: fix static linking with snappy > + > +snappy is a C++ library so cxx linker must be used to avoid errors > +when statically linking: > + > +/home/buildroot/autobuild/instance-1/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libsnappy.a(snappy.cc.o): In function `snappy::internal::WorkingMemory::GetHashTable(unsigned int, int*)': > +snappy.cc:(.text+0x358): undefined reference to `operator new[](unsigned int)' > + > +Fixes: > + - http://autobuild.buildroot.org/results/faa65da84ace974426e220205f4665fc0a73bdfe > + > +Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > +--- > + CMakeLists.txt | 30 ++++++++++++++++++++++++++++++ > + 1 file changed, 30 insertions(+) > + > +diff --git a/CMakeLists.txt b/CMakeLists.txt > +index e2fdafc227..cf5b8dfd56 100644 > +--- a/CMakeLists.txt > ++++ b/CMakeLists.txt > +@@ -2191,6 +2191,11 @@ if(BUILD_wireshark AND QT_FOUND) > + if(ENABLE_APPLICATION_BUNDLE OR WIN32) > + set_target_properties(wireshark PROPERTIES OUTPUT_NAME Wireshark) > + endif() > ++ # epan links with snappy which is a C++ library so use cxx linker to > ++ # avoid error when statically linking > ++ if(SNAPPY_FOUND) > ++ set_target_properties(wireshark PROPERTIES LINKER_LANGUAGE CXX) > ++ endif(SNAPPY_FOUND) > + > + if(ENABLE_APPLICATION_BUNDLE) > + add_dependencies(wireshark manpages) > +@@ -2306,6 +2311,11 @@ if(BUILD_tshark) > + add_executable(tshark ${tshark_FILES}) > + set_extra_executable_properties(tshark "Executables") > + target_link_libraries(tshark ${tshark_LIBS}) > ++ # epan links with snappy which is a C++ library so use cxx linker to > ++ # avoid error when statically linking > ++ if(SNAPPY_FOUND) > ++ set_target_properties(tshark PROPERTIES LINKER_LANGUAGE CXX) > ++ endif(SNAPPY_FOUND) > + install(TARGETS tshark RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) > + endif() > + > +@@ -2329,6 +2339,11 @@ if(BUILD_tfshark) > + add_executable(tfshark ${tfshark_FILES}) > + set_extra_executable_properties(tfshark "Executables") > + target_link_libraries(tfshark ${tfshark_LIBS}) > ++ # epan links with snappy which is a C++ library so use cxx linker to > ++ # avoid error when statically linking > ++ if(SNAPPY_FOUND) > ++ set_target_properties(tfshark PROPERTIES LINKER_LANGUAGE CXX) > ++ endif(SNAPPY_FOUND) > + install(TARGETS tfshark RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) > + endif() > + > +@@ -2352,6 +2367,11 @@ if(BUILD_rawshark AND PCAP_FOUND) > + add_executable(rawshark ${rawshark_FILES}) > + set_extra_executable_properties(rawshark "Executables") > + target_link_libraries(rawshark ${rawshark_LIBS}) > ++ # epan links with snappy which is a C++ library so use cxx linker to > ++ # avoid error when statically linking > ++ if(SNAPPY_FOUND) > ++ set_target_properties(rawshark PROPERTIES LINKER_LANGUAGE CXX) > ++ endif(SNAPPY_FOUND) > + install(TARGETS rawshark RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) > + endif() > + > +@@ -2383,6 +2403,11 @@ if(BUILD_sharkd) > + if(WIN32) > + target_link_libraries(sharkd "ws2_32.lib") > + endif(WIN32) > ++ # epan links with snappy which is a C++ library so use cxx linker to > ++ # avoid error when statically linking > ++ if(SNAPPY_FOUND) > ++ set_target_properties(sharkd PROPERTIES LINKER_LANGUAGE CXX) > ++ endif(SNAPPY_FOUND) > + > + install(TARGETS sharkd RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) > + endif() > +@@ -2400,6 +2425,11 @@ if(BUILD_dftest) > + add_executable(dftest ${dftest_FILES}) > + set_extra_executable_properties(dftest "Tests") > + target_link_libraries(dftest ${dftest_LIBS}) > ++ # epan links with snappy which is a C++ library so use cxx linker to > ++ # avoid error when statically linking > ++ if(SNAPPY_FOUND) > ++ set_target_properties(dftest PROPERTIES LINKER_LANGUAGE CXX) > ++ endif(SNAPPY_FOUND) > + endif() > + > + if(BUILD_randpkt) > +-- > +2.20.1 > + > -- > 2.20.1 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
diff --git a/package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch b/package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch new file mode 100644 index 0000000000..e9233aa90f --- /dev/null +++ b/package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch @@ -0,0 +1,98 @@ +From eb226af7ae998cda6b9747d9e77692fda85563bc Mon Sep 17 00:00:00 2001 +From: Fabrice Fontaine <fontaine.fabrice@gmail.com> +Date: Tue, 28 May 2019 21:26:19 +0200 +Subject: [PATCH] CMakeLists.txt: fix static linking with snappy + +snappy is a C++ library so cxx linker must be used to avoid errors +when statically linking: + +/home/buildroot/autobuild/instance-1/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libsnappy.a(snappy.cc.o): In function `snappy::internal::WorkingMemory::GetHashTable(unsigned int, int*)': +snappy.cc:(.text+0x358): undefined reference to `operator new[](unsigned int)' + +Fixes: + - http://autobuild.buildroot.org/results/faa65da84ace974426e220205f4665fc0a73bdfe + +Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> +--- + CMakeLists.txt | 30 ++++++++++++++++++++++++++++++ + 1 file changed, 30 insertions(+) + +diff --git a/CMakeLists.txt b/CMakeLists.txt +index e2fdafc227..cf5b8dfd56 100644 +--- a/CMakeLists.txt ++++ b/CMakeLists.txt +@@ -2191,6 +2191,11 @@ if(BUILD_wireshark AND QT_FOUND) + if(ENABLE_APPLICATION_BUNDLE OR WIN32) + set_target_properties(wireshark PROPERTIES OUTPUT_NAME Wireshark) + endif() ++ # epan links with snappy which is a C++ library so use cxx linker to ++ # avoid error when statically linking ++ if(SNAPPY_FOUND) ++ set_target_properties(wireshark PROPERTIES LINKER_LANGUAGE CXX) ++ endif(SNAPPY_FOUND) + + if(ENABLE_APPLICATION_BUNDLE) + add_dependencies(wireshark manpages) +@@ -2306,6 +2311,11 @@ if(BUILD_tshark) + add_executable(tshark ${tshark_FILES}) + set_extra_executable_properties(tshark "Executables") + target_link_libraries(tshark ${tshark_LIBS}) ++ # epan links with snappy which is a C++ library so use cxx linker to ++ # avoid error when statically linking ++ if(SNAPPY_FOUND) ++ set_target_properties(tshark PROPERTIES LINKER_LANGUAGE CXX) ++ endif(SNAPPY_FOUND) + install(TARGETS tshark RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) + endif() + +@@ -2329,6 +2339,11 @@ if(BUILD_tfshark) + add_executable(tfshark ${tfshark_FILES}) + set_extra_executable_properties(tfshark "Executables") + target_link_libraries(tfshark ${tfshark_LIBS}) ++ # epan links with snappy which is a C++ library so use cxx linker to ++ # avoid error when statically linking ++ if(SNAPPY_FOUND) ++ set_target_properties(tfshark PROPERTIES LINKER_LANGUAGE CXX) ++ endif(SNAPPY_FOUND) + install(TARGETS tfshark RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) + endif() + +@@ -2352,6 +2367,11 @@ if(BUILD_rawshark AND PCAP_FOUND) + add_executable(rawshark ${rawshark_FILES}) + set_extra_executable_properties(rawshark "Executables") + target_link_libraries(rawshark ${rawshark_LIBS}) ++ # epan links with snappy which is a C++ library so use cxx linker to ++ # avoid error when statically linking ++ if(SNAPPY_FOUND) ++ set_target_properties(rawshark PROPERTIES LINKER_LANGUAGE CXX) ++ endif(SNAPPY_FOUND) + install(TARGETS rawshark RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) + endif() + +@@ -2383,6 +2403,11 @@ if(BUILD_sharkd) + if(WIN32) + target_link_libraries(sharkd "ws2_32.lib") + endif(WIN32) ++ # epan links with snappy which is a C++ library so use cxx linker to ++ # avoid error when statically linking ++ if(SNAPPY_FOUND) ++ set_target_properties(sharkd PROPERTIES LINKER_LANGUAGE CXX) ++ endif(SNAPPY_FOUND) + + install(TARGETS sharkd RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}) + endif() +@@ -2400,6 +2425,11 @@ if(BUILD_dftest) + add_executable(dftest ${dftest_FILES}) + set_extra_executable_properties(dftest "Tests") + target_link_libraries(dftest ${dftest_LIBS}) ++ # epan links with snappy which is a C++ library so use cxx linker to ++ # avoid error when statically linking ++ if(SNAPPY_FOUND) ++ set_target_properties(dftest PROPERTIES LINKER_LANGUAGE CXX) ++ endif(SNAPPY_FOUND) + endif() + + if(BUILD_randpkt) +-- +2.20.1 +
Fixes: - http://autobuild.buildroot.org/results/419468f0d7d3c2b64d420513aa9505c6de097ed2 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- Changes v1 -> v2 (after review of Arnout Vandecappelle): - Set linker to CXX instead of adding -lstdc++ to LIBS ...s.txt-fix-static-linking-with-snappy.patch | 98 +++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 package/wireshark/0005-CMakeLists.txt-fix-static-linking-with-snappy.patch