Wireshark-bugs: [Wireshark-bugs] [Bug 7403] [PATCH] epan/Makefile.am filters out python-related

Date: Sat, 8 Sep 2012 17:41:19 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7403

--- Comment #18 from pi-rho <ubuntu@xxxxxx> 2012-09-08 17:41:18 PDT ---
(In reply to comment #17)
> (In reply to comment #15)
> > Just to be clear, my first patch, now deprecated, corrected a logic error.
> 
> ...and isn't now deprecated, it's now marked as "accepted for checkin", and is
> still in epan/Makefile.am - the attempt to back it out in 44805 changed the
> wrong "HAVE_LIBPY", which broke the build and was undone.

Sorry, I don't have visibility of a "accepted for checkin" marker. I'm happy
updating the 9098 patch.

> > With https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9098, it needs the
> > positive condition to trigger and use awk to append to libwireshark.sym.
> 
> That change should be made for the HAVE_PLUGINS optional symbols as well.

That makes sense.

> > That being said, applying both
> > https://bugs.wireshark.org/bugzilla/attachment.cgi?id=8681 and
> > https://bugs.wireshark.org/bugzilla/attachment.cgi?id=9098 will be incorrect.
> 
> Then 9098 should be replaced with a patch that applies to the current version
> of epan/Makefile.am, which has had the change in 8681 made (as that change
> fixed a logic error, and did not, in and of itself, break the build, it should
> not be reverted), and that also changes the HAVE_PLUGINS optional symbols
> stuff.

OK.  The patch would have to include the current epan/Makefile.am and
epan/libwireshark.def (to remove the plugin symbols from the base .def).  The
Windows build environment, however, uses epan/libwireshark.def directly. If
Gawk (from cygwin) is added to the Windows build environment, something similar
can be done with nmake.

> > The first two patches failed on Solaris and OSX because some of the symbols
> > added to libwireshark.def weren't being filtered out. I was about to upload an
> > updated patch that had an updated filter, but realized that it would never work
> > on Windows, since the .def is being used directly -- and the .def file is a
> > native configuration file for Microsoft's LINK.
> 
> But that doesn't support libpy support on Windows - it'd be best to have a
> mechanism for optionally-exported symbols that works with make, CMake, and
> MSVC++ nmake.

Agreed.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.