[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static
https://bugs.exim.org/show_bug.cgi?id=1681 Zoltan Herczeg changed: What|Removed |Added CC||hzmes...@freemail.hu --- Comment #1 from Zoltan Herczeg --- I think the license block should be adapted to PCRE. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1683] New: libpcrecpp recipe does not honor -force_cpusubtype_ALL on OS X
https://bugs.exim.org/show_bug.cgi?id=1683 Bug ID: 1683 Summary: libpcrecpp recipe does not honor -force_cpusubtype_ALL on OS X Product: PCRE Version: 8.37 Hardware: Other OS: MacOS X Status: NEW Severity: bug Priority: medium Component: Code Assignee: p...@hermes.cam.ac.uk Reporter: noloa...@gmail.com CC: pcre-dev@exim.org I am using the original PCRE library due to Git (Git requires it, and its `configure` fails a check for `pcre_version` if using PCRE2). I configured with the following: export CFLAGS="-arch ppc -force_cpusubtype_ALL" export LDFLAGS="-Wl,-force_cpusubtype_ALL" ./configure --enable-static --enable-shared --enable-utf --enable-pcre8 \ --enable-pcre16 --enable-pcre32 --enable-unicode-properties \ --enable-newline-is-any --enable-pcregrep-libz --enable-pcregrep-libbz2 \ --with-gnu-ld --prefix=/usr/local/ppc I then did the same for PPC64 using "export CFLAGS="-arch ppc64 -force_cpusubtype_ALL" When I attempted to build a fat libpcrecpp.a, it resulted in an error: sudo lipo -create /usr/local/ppc/lib/libpcrecpp.a \ /usr/local/ppc64/lib/libpcrecpp.a \ -output /usr/local/lib/libpcrecpp.a lipo: /usr/local/ppc/lib/libpcrecpp.a and /usr/local/ppc64/lib/libpcrecpp.a have the same architectures (ppc7400) and can't be in the same fat output file Based on: $ lipo -info /usr/local/ppc/lib/libpcrecpp.a input file /usr/local/ppc/lib/libpcrecpp.a is not a fat file Non-fat file: /usr/local/ppc/lib/libpcrecpp.a is architecture: ppc7400 $ lipo -info /usr/local/ppc64/lib/libpcrecpp.a input file /usr/local/ppc64/lib/libpcrecpp.a is not a fat file Non-fat file: /usr/local/ppc64/lib/libpcrecpp.a is architecture: ppc7400 I'm guessing libpcrecpp is not utilizing CFLAGS. The other library recipes do honor CFLAGS and the options "-arch ppc -force_cpusubtype_ALL", and lipo creates the fat binaries. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1682] New: Test #2 failure related to /dev/null
https://bugs.exim.org/show_bug.cgi?id=1682 Bug ID: 1682 Summary: Test #2 failure related to /dev/null Product: PCRE Version: 8.37 Hardware: x86-64 OS: Windows Status: NEW Severity: bug Priority: medium Component: Code Assignee: p...@hermes.cam.ac.uk Reporter: luke1...@gmx.de CC: pcre-dev@exim.org building PCRE 8.37 I'm getting the following test failure when running RunTest.bat: Test 2: "Test with Study Override" failed comparison: fc /n .\testdata\testoutput2 testoutstudy8\testoutput2 Comparing the two files, the following output differs in line 5618f.: reference file (testdata/testoutput2): No match //KF>/dev/null Compiled pattern written to /dev/null Study data written to /dev/null /abc/IS>testsavedregex test-output file (testoutstudy8/testoutput2): No match //KF>/dev/null Unable to open /dev/null: No such file or directory /abc/IS>testsavedregex The cmake command I used to configure the build is: cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_EXE_LINKER_FLAGS:STRING=-STACK:8388608 -DCMAKE_INSTALL_PREFIX:PATH=G:\Source\Subversion\dependencies\httpd\srclib\pcre . -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1681] New: CMake compiles PCRE dynamically even when set to static
https://bugs.exim.org/show_bug.cgi?id=1681 Bug ID: 1681 Summary: CMake compiles PCRE dynamically even when set to static Product: PCRE Version: 8.37 Hardware: x86 OS: Windows Status: NEW Severity: bug Priority: medium Component: Code Assignee: p...@hermes.cam.ac.uk Reporter: chris+e...@qwirx.com CC: pcre-dev@exim.org Created attachment 833 --> https://bugs.exim.org/attachment.cgi?id=833&action=edit CMake configuration file to enable static runtime The CMake configuration allows building a "static library", but this is compiled by MSVC with the "/MD" (DLL) option, so it uses the dynamic runtime instead of static, which makes it impossible to produce a fully static binary as output. The solution is to modify the CMAKE_C_FLAGS when building statically. This seems to be a well-known limitation of CMake: http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F http://www.cmake.org/pipermail/cmake/2010-January/034592.html https://raw.githubusercontent.com/webmproject/libwebm/master/build/msvc_runtime.cmake http://stackoverflow.com/questions/16212682/why-does-this-cmake-project-not-set-the-appropriate-msvc-runtime I added the following file as cmake/msvc_runtime.cmake (derived from the WebM file linked above): ## Copyright (c) 2015 The WebM project authors. All Rights Reserved. ## ## Use of this source code is governed by a BSD-style license ## that can be found in the LICENSE file in the root of the source ## tree. An additional intellectual property rights grant can be found ## in the file PATENTS. All contributing project authors may ## be found in the AUTHORS file in the root of the source tree. cmake_minimum_required(VERSION 2.8) if(WIN32) # CMake defaults to producing code linked to the DLL MSVC runtime. In libwebm # static is typically desired. Force static code generation unless the user # running CMake set MSVC_RUNTIME to dll. if(PCRE_STATIC) message(STATUS "MSVC -> forcing use of statically-linked runtime.") foreach(flag_var CMAKE_C_FLAGS CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO) string(REPLACE "/MD " "/MT " ${flag_var} "${${flag_var}}") string(REPLACE "/MDd " "/MTd " ${flag_var} "${${flag_var}}") endforeach(flag_var) endif(PCRE_STATIC) endif(WIN32) And then added the following line to CMakeLists.txt after "ENDIF(NOT BUILD_SHARED_LIBS)": INCLUDE(msvc_runtime) Thanks for your consideration! -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)
https://bugs.exim.org/show_bug.cgi?id=1679 --- Comment #11 from henrik.h...@aol.de --- What about spacing the contents of "(*MARK:...)" out like the rest of the pattern and to use "\ "? -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)
https://bugs.exim.org/show_bug.cgi?id=1679 --- Comment #10 from henrik.h...@aol.de --- That's good! So now, any fixed (non-dynamic) replacement should work using "(*MARK:...)". -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1679] Ability to explicitly specify what to capture (feature request)
https://bugs.exim.org/show_bug.cgi?id=1679 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Philip Hazel --- You don't need another ticket. I have added a new option PCRE2_ALT_VERBNAMES to pcre2_compile(). When it is set, normal backslash processing is applied so you can use \) to include a closing parenthesis. The option is needed so that the default processing is compatible with Perl. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev