[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

2015-08-30 Thread admin
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

2015-08-30 Thread admin
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

2015-08-30 Thread admin
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

2015-08-30 Thread admin
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)

2015-08-30 Thread admin
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)

2015-08-30 Thread admin
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)

2015-08-30 Thread admin
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