Re: [tcpdump-workers] Need precompiled source files in libpcap
On Jun 24, 2016, at 8:58 PM, Yang Luo wrote: > I found that there are a lot of “precompiled source code files" like > grammar.c, scanner.c, grammar.h, ,scanner.h, etc. (which are also listed in > .gitignore). They are NOT contained in the libpcap repo. > > I personally want to ship them in the "Win32-Extensions" folder of the Npcap > repo, so the Npcap developers can just build the "libpcap.sln" project with > one click, and will get the wpcap.dll. > > Do you think this is a good idea? Or Windows developers should also build > everything from the bottom? You can either 1) install Flex and Bison yourself, use them to build those files, and ship them with the Npcap source (along with the .y and .l files!) or 2) require that developers install Flex and Bison. You will need Flex 2.5.31 or later. See, for example https://sourceforge.net/projects/winflexbison/ for Flex and Bison for Windows. > I noticed this docs: > https://github.com/the-tcpdump-group/libpcap/blob/master/INSTALL.txt, and it > seems to require to run "./configure" (a shell script), which is for Linux. > So I think there's no Windows alternative config command for now? The autoconf script is UN*X-only. (It's not "for Linux", it's for Linux and OS X and FreeBSD and NetBSD and OpenBSD and DragonFly BSD and Solaris and HP-UX and AIX and even, assuming it still works, older dead UN*Xes.) We also support CMake: https://cmake.org on both UN*X *and* Windows. > And installing flex and bison for Windows are not also very friendly. https://twitter.com/geraldcombs/status/735870968451629056 > And I think those source files are less likely to change as frequently as > other sources. That is not necessarily true. Any time new operators are added to the packet filter language, either scanner.l or grammar.y or both will be changed. > I think just ship them in Npcap repo will be a good idea? We won't be putting the generated versions into the libpcap repository, and I would *not* recommend putting them into the Npcap repository. *If* you want to provide the generated source files in the Npcap source release, as they're provided in libpcap source releases, I would recommend that you generate them as part of the process of building an Npcap source release. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Need precompiled source files in libpcap
Hi Guy, On Sat, Jun 25, 2016 at 3:09 PM, Guy Harris wrote: > On Jun 24, 2016, at 8:58 PM, Yang Luo wrote: > > > I found that there are a lot of “precompiled source code files" like > grammar.c, scanner.c, grammar.h, ,scanner.h, etc. (which are also listed in > .gitignore). They are NOT contained in the libpcap repo. > > > > I personally want to ship them in the "Win32-Extensions" folder of the > Npcap repo, so the Npcap developers can just build the "libpcap.sln" > project with one click, and will get the wpcap.dll. > > > > Do you think this is a good idea? Or Windows developers should also > build everything from the bottom? > > You can either > > 1) install Flex and Bison yourself, use them to build those files, > and ship them with the Npcap source (along with the .y and .l files!) > I have successfully built libpcap on my Ubuntu, and got the generated source files. They can be used in the Windows build process. Currently, I assume that Npcap has those files (but I didn't push them to the remote). I just made a pull request about the current progress. > > or > > 2) require that developers install Flex and Bison. > In future, I will make sure that the Windows developers compile those generated source files. > > You will need Flex 2.5.31 or later. See, for example > > https://sourceforge.net/projects/winflexbison/ > > for Flex and Bison for Windows. > I will try the Windows version Flex and Bison later. Besides these two things, are there other files that need to be prebuilt? I know I need to read the "configure" file in the root dir to see what it does, but this file is too long.. If you can tell me what needs to be pre-built besides those two, it would be great.. > > > I noticed this docs: > https://github.com/the-tcpdump-group/libpcap/blob/master/INSTALL.txt, and > it seems to require to run "./configure" (a shell script), which is for > Linux. So I think there's no Windows alternative config command for now? > > The autoconf script is UN*X-only. (It's not "for Linux", it's for Linux > and OS X and FreeBSD and NetBSD and OpenBSD and DragonFly BSD and Solaris > and HP-UX and AIX and even, assuming it still works, older dead UN*Xes.) > OK. I usually say all UNIX, LINUX systems as Linux for short.. At least for me, they don't differ too much.. I will try to say UN*X instead of Linux. > We also support CMake: > > https://cmake.org > > on both UN*X *and* Windows. > Can CMake do what the UN*X "./configure" command does? On Windows, the build is very easy, just click "build" in Visual Studio. But the ".configure" process seems to have no replacement on Windows. Is that CMake? > > > And installing flex and bison for Windows are not also very friendly. > > https://twitter.com/geraldcombs/status/735870968451629056 > > > And I think those source files are less likely to change as frequently > as other sources. > > That is not necessarily true. Any time new operators are added to the > packet filter language, either scanner.l or grammar.y or both will be > changed. > This is why I think Npcap will build those generated source files too. > > > I think just ship them in Npcap repo will be a good idea? > > We won't be putting the generated versions into the libpcap repository, > and I would *not* recommend putting them into the Npcap repository. *If* > you want to provide the generated source files in the Npcap source release, > as they're provided in libpcap source releases, I would recommend that you > generate them as part of the process of building an Npcap source release. Have you put the generated source files into the source release? I didn't see it. I have downloaded libpcap-libpcap-1.7.4.zip from https://github.com/the-tcpdump-group/libpcap/releases/tag/libpcap-1.7.4. (I don't know why the zip file name has two "libpcap" strings). Then unzipped it. I didn't see any of grammar.c, scanner.c, grammar.h, ,scanner.h. I only see a file named "scanner.c.top". Cheers, Yang ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Is it OK to rename the MSVC project name from "libpcap" to "wpcap"?
Hi list, We know that the libpcap Windows version is called "wpcap", including the project files names (wpcap.sln, wpcap.vcxproj) and the library name (wpcap.dll). But the current libpcap trunk project is called "libpcap.sln", and the built executable is named as "libpcap.dll". Is it OK to rename the MSVC project name from "libpcap" to "wpcap"? Cheers, Yang ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Need precompiled source files in libpcap
On Jun 25, 2016, at 7:25 AM, Yang Luo wrote: > On Sat, Jun 25, 2016 at 3:09 PM, Guy Harris wrote: > >> On Jun 24, 2016, at 8:58 PM, Yang Luo wrote: >> >>> I found that there are a lot of “precompiled source code files" like >>> grammar.c, scanner.c, grammar.h, ,scanner.h, etc. (which are also listed in >>> .gitignore). They are NOT contained in the libpcap repo. >>> >>> I personally want to ship them in the "Win32-Extensions" folder of the >>> Npcap repo, so the Npcap developers can just build the "libpcap.sln" >>> project with one click, and will get the wpcap.dll. >>> >>> Do you think this is a good idea? Or Windows developers should also build >>> everything from the bottom? >> >> You can either >> >> 1) install Flex and Bison yourself, use them to build those files, >> and ship them with the Npcap source (along with the .y and .l files!) > > I have successfully built libpcap on my Ubuntu, and got the generated source > files. They can be used in the Windows build process. I wouldn't rely on a UN*X version of Flex or Bison generating a file that can be built on Windows; for example, some versions of either Flex or Bison would generate source files that included , which is a UN*X-specific header file. This also means that if you have a source directory on a file server, or that's otherwise shared between multiple operating systems, and the software uses Flex or Bison, and you've just done a UN*X build in that directory, if you're going to do a Windows build, you may need to do not just a clean (to get rid of object files), you may need to do a "distclean" or whatever clean operation removes generated files (to get rid of files generated by Flex or Bison) - people have had problems with Wireshark builds due to not getting rid of the generated files first. >> or >> >> 2) require that developers install Flex and Bison. > > In future, I will make sure that the Windows developers compile those > generated source files. That's the best solution. >> You will need Flex 2.5.31 or later. See, for example >> >> https://sourceforge.net/projects/winflexbison/ >> >> for Flex and Bison for Windows. > > I will try the Windows version Flex and Bison later. The section in the Wireshark Developer's Guide on setting up a Windows environment: https://www.wireshark.org/docs/wsdg_html_chunked/ChSetupWin32.html includes instructions on setting up Flex and Bison, as Wireshark also requires them. > Besides these two things, are there other files that need to be prebuilt? I > know I need to read the "configure" file in the root dir to see what it does, No, the "configure" file is *itself* a generated file - the source is in configure.ac and aclocal.m4 - so you don't want to read it (unless you're trying to debug a problem in the configure script itself). The best thing to read would be the Makefile.in file, which is the template from which the configure script generates the Makefile. What you should look for are lines of the form X.c: ... and X.h: ... which are Makefile rules to generate .c and .h files. > but this file is too long.. > If you can tell me what needs to be pre-built besides those two, it would be > great.. The other generated files are: version.c, version.h - unfortunately, generating those from the VERSION file requires several UN*X tools, so you'd have to either: require developers to install Windows versions of those tools from Cygwin or some other place; come up with an equivalent procedure that uses tools that come with Windows; manually generate them. bpf_filter.c - currently, the BPF interpreter is in a subdirectory of the source directory (so that it can be picked up and dropped into a UN*X kernel; that's probably not that necessary these days, as UN*Xes have their own versions in their source trees, and they need to pick up any changes we make to the libpcap BPF interpreter by hand), and the build procedure makes a symbolic link to it. For Windows, you probably should make a copy for now; I'll ask whether it's time to just put the BPF interpreter in the top-level libpcap source directory. > I noticed this docs: > https://github.com/the-tcpdump-group/libpcap/blob/master/INSTALL.txt, and it > seems to require to run "./configure" (a shell script), which is for Linux. > So I think there's no Windows alternative config command for now? No, and there are no plans to have the autoconf script work for Windows. >> We also support CMake: >> >> https://cmake.org >> >> on both UN*X *and* Windows. > > Can CMake do what the UN*X "./configure" command does? It's supposed to. On UN*Xes, it doesn't yet do *all* the things that the configure command does - there are some XXX comments in CMakeLists.txt about that. I eventually plan to make it do all the checks in question. On Windows, it should do all the necessary chec
Re: [tcpdump-workers] Is it OK to rename the MSVC project name from "libpcap" to "wpcap"?
On Jun 25, 2016, at 8:01 AM, Yang Luo wrote: > We know that the libpcap Windows version is called "wpcap", including the > project files names (wpcap.sln, wpcap.vcxproj) and the library name > (wpcap.dll). But the current libpcap trunk project is called "libpcap.sln", > and the built executable is named as "libpcap.dll". > > Is it OK to rename the MSVC project name from "libpcap" to "wpcap"? Ideally, WinPcap would just have called it "pcap.dll", rather than "wpcap.dll", for consistency with UN*X. (The "lib" at the beginning of library names is a UNIX convention, which all UN*Xes - including the ones not based on AT&T code - have adopted; if you want to link with a library called "foo", you link with "-lfoo", and that searches for "libfoo.a" (static library) and, on systems that support dynamic linking, "libfoo.so" or "libfoo.dylib" or "libfoo.sl" or whatever the UN*X you're on uses for shared/dynamic libraries.) In that case, the Windows files would begin with just "pcap", and that would be the project name. However, they didn't, so, for backwards compatibility, we need to call the library "wpcap", rather than "pcap", when building on Windows. I've updated the CMakeLists.txt file to do so. The MSVC project files - if we continue to provide them at all - should be updated to do so as well. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Is it OK to rename the MSVC project name from "libpcap" to "wpcap"?
Hi Guy, Thanks! Then I will rename the MSVC project files later if you didn't do that. Cheers, Yang On Sun, Jun 26, 2016 at 8:21 AM, Guy Harris wrote: > On Jun 25, 2016, at 8:01 AM, Yang Luo wrote: > > > We know that the libpcap Windows version is called "wpcap", including > the project files names (wpcap.sln, wpcap.vcxproj) and the library name > (wpcap.dll). But the current libpcap trunk project is called "libpcap.sln", > and the built executable is named as "libpcap.dll". > > > > Is it OK to rename the MSVC project name from "libpcap" to "wpcap"? > > Ideally, WinPcap would just have called it "pcap.dll", rather than > "wpcap.dll", for consistency with UN*X. > > (The "lib" at the beginning of library names is a UNIX convention, which > all UN*Xes - including the ones not based on AT&T code - have adopted; if > you want to link with a library called "foo", you link with "-lfoo", and > that searches for "libfoo.a" (static library) and, on systems that support > dynamic linking, "libfoo.so" or "libfoo.dylib" or "libfoo.sl" or whatever > the UN*X you're on uses for shared/dynamic libraries.) > > In that case, the Windows files would begin with just "pcap", and that > would be the project name. > > However, they didn't, so, for backwards compatibility, we need to call the > library "wpcap", rather than "pcap", when building on Windows. > > I've updated the CMakeLists.txt file to do so. The MSVC project files - > if we continue to provide them at all - should be updated to do so as well. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Is it OK to rename the MSVC project name from "libpcap" to "wpcap"?
On Jun 25, 2016, at 5:56 PM, Yang Luo wrote: > Thanks! Then I will rename the MSVC project files later if you didn't do that. I haven't renamed them. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
