Error when building: pcre2.h couldn't be found

[jacobmolby]

When building in Xcode I get the following error:

Showing Recent Messages
PhaseScriptExecution [CP-User]\ Build\ native\ dependencies /Users/jacobmolby/Library/Developer/Xcode/DerivedData/APP-ciqjfzmzsyjvmxaavhcdmnjhssfk/Build/Intermediates.noindex/Pods.build/Debug-iphoneos/dr-pogodin-react-native-static-server.build/Script-46EB2E00024900.sh (in target 'dr-pogodin-react-native-static-server' from project 'Pods')

#.... exports

CMake Warning (dev) at CMakeLists.txt:25:
  Syntax Warning in cmake code at column 29

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:26:
  Syntax Warning in cmake code at column 30

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:27:
  Syntax Warning in cmake code at column 30

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:1 (project):
  Policy CMP0048 is not set: project() command manages VERSION variables.
  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  The following variable(s) would be set to empty:

    CMAKE_PROJECT_VERSION
    CMAKE_PROJECT_VERSION_MAJOR
    CMAKE_PROJECT_VERSION_MINOR
    CMAKE_PROJECT_VERSION_PATCH
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Could not find OPTIONAL package Readline
-- Could not find OPTIONAL package Editline
-- 
-- 
-- PCRE2-10.42 configuration summary:
-- 
--   Install prefix .................. : /usr/local
--   C compiler ...................... : /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
--   C compiler flags ................ : 
-- 
--   Build 8 bit PCRE2 library ....... : ON
--   Build 16 bit PCRE2 library ...... : OFF
--   Build 32 bit PCRE2 library ...... : OFF
--   Enable JIT compiling support .... : OFF
--   Use SELinux allocator in JIT .... : IGNORE
--   Enable Unicode support .......... : ON
--   Newline char/sequence ........... : LF
--   \R matches only ANYCRLF ......... : OFF
--   \C is disabled .................. : OFF
--   EBCDIC coding ................... : OFF
--   EBCDIC coding with NL=0x25 ...... : OFF
--   Rebuild char tables ............. : OFF
--   Internal link size .............. : 2
--   Parentheses nest limit .......... : 250
--   Heap limit ...................... : 20000000
--   Match limit ..................... : 10000000
--   Match depth limit ............... : MATCH_LIMIT
--   Build shared libs ............... : OFF
--   Build static libs ............... : ON
--      with PIC enabled ............. : OFF
--   Build pcre2grep ................. : ON
--   Enable JIT in pcre2grep ......... : ON
--   Enable callouts in pcre2grep .... : ON
--   Enable callout fork in pcre2grep. : ON
--   Buffer size for pcre2grep ....... : 20480
--   Build tests (implies pcre2test .. : ON
--                and pcre2grep)
--   Link pcre2grep with libz ........ : ON
--   Link pcre2grep with libbz2 ...... : ON
--   Link pcre2test with libeditline . : Library not found
--   Link pcre2test with libreadline . : Library not found
--   Support Valgrind .................: OFF
--   Use %zu and %td ..................: AUTO
-- 
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
-- found pcre2-config: no
CMake Error at lighttpd1.4/src/CMakeLists.txt:574 (message):
  pcre2.h couldn't be found

I'm running on a Mac with M2 chip.

• react-native@0.70.6
• @dr.pogodin/react-native-static-server@0.7.0

CMake (and pcre2) is installed with Homebrew.

I would think it is an issue with Apple Sillicon, but I don't know.... I hope you can help :)

[jacobmolby]

It works fine with v0.6.0-alpha.8, but of course that doesn't use lighttpd1.4, which is the culprit.

[birdofpreyru]

Hi @jacobmolby .

The idea with pcre2 is that its source is included into the library package (you'll find it under node_modules/@dr.pogodin/react-native-static-server/pcre2), and compiled for the target system during the build. I guess, I messed up something in related CMake configuration files, and haven't noticed due to not re-running the entire build of a test project from a completely clean state.

A quick workaround is to build Lighttpd without pcre2, for that you can edit node_modules/@dr.pogodin/react-native-static-server/dr-pogodin-react-native-static-server.podspec, adding to this block the -DWITH_PCRE2=OFF argument, then do pod install and re-build.

The root cause solution will be to dig into the library and lighttpd CMakeLists files (1, 2), and correct them. I myself probably only arrive to do it some week(s) later, as now all my time available for this project I spend on trying to make it work for Windows 😭

[jacobmolby]

Thanks for the quick response! It seemed to work :D

I also had to add homebrew to path, otherwise cmake was not recognised.

My full patch looks like this:

diff --git a/node_modules/@dr.pogodin/react-native-static-server/dr-pogodin-react-native-static-server.podspec b/node_modules/@dr.pogodin/react-native-static-server/dr-pogodin-react-native-static-server.podspec
index 7aba925..399b993 100644
--- a/node_modules/@dr.pogodin/react-native-static-server/dr-pogodin-react-native-static-server.podspec
+++ b/node_modules/@dr.pogodin/react-native-static-server/dr-pogodin-react-native-static-server.podspec
@@ -31,12 +31,15 @@ Pod::Spec.new do |s|
    #],
    :script => <<-CMD
      set -e
+      # Add Homebrew's CMake to the PATH
+      export PATH=/opt/homebrew/bin:$PATH
      cmake ${PODS_TARGET_SRCROOT} -B ${TARGET_TEMP_DIR} \
        -DCMAKE_OSX_DEPLOYMENT_TARGET=${IPHONEOS_DEPLOYMENT_TARGET} \
        -DCMAKE_SYSTEM_NAME=iOS \
        -DBUILD_STATIC=1 \
        -DBUILD_LIBRARY=1 \
-        -GXcode
+        -GXcode \
+        -DWITH_PCRE2=OFF # See https://github.com/birdofpreyru/react-native-static-server/issues/18
      cmake --build ${TARGET_TEMP_DIR} --config ${CONFIGURATION} \
        --target pcre2-8-static mod_indexfile mod_dirlisting mod_staticfile \
          lighttpd

[jacobmolby]

Edit: I found that I haven't increased the minSdkVersion to 28. My bad :)

However I cannot seem to build with Android.

I get this error:

in-x86_64/sysroot/usr/lib/aarch64-linux-android/libz.a  -latomic -lm && :
  lighttpd1.4/build/CMakeFiles/lighttpd.dir/configfile.c.o: In function `config_parse_file':
  /Users/jacobmolby/code/APP/node_modules/@dr.pogodin/react-native-static-server/android/.cxx/Debug/1l6t106b/arm64-v8a/../../../../../lighttpd1.4/src/configfile.c:2246: undefined reference to `glob'
  /Users/jacobmolby/code/APP/node_modules/@dr.pogodin/react-native-static-server/android/.cxx/Debug/1l6t106b/arm64-v8a/../../../../../lighttpd1.4/src/configfile.c:2252: undefined reference to `globfree'
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  ninja: build stopped: subcommand failed.

I tried to add -DWITH_PCRE2=OFF in build.gradle

android {
  compileSdkVersion getExtOrIntegerDefault("compileSdkVersion")

  defaultConfig {
    minSdkVersion getExtOrIntegerDefault("minSdkVersion")
    targetSdkVersion getExtOrIntegerDefault("targetSdkVersion")
    buildConfigField "boolean", "IS_NEW_ARCHITECTURE_ENABLED", isNewArchitectureEnabled().toString()
    externalNativeBuild {
      cmake {
        arguments "-DWITH_PCRE2=OFF", "-DWITH_ANDROID_NDK_SYSLOG_INTERCEPT=ON", "-DWITH_JAVA_NATIVE_INTERFACE=ON", "-DBUILD_STATIC=ON"
        targets "pcre2-8-static", "mod_indexfile", "mod_dirlisting", "mod_staticfile", "lighttpd"
      }
    }
  }

But it doesn't seem to work. I get the same error regardless, I don't know if it is related to the issue on iOS

[birdofpreyru]

@jacobmolby on Android it is a different issue. Set minSdkVersion equal 28 ; the glob library is a part of Android SDK starting from that version.

[jacobmolby]

Yeah, I figured from Googling and remembering reading about in the docs :) Thanks.

[gstrauss]

@birdofpreyru

I myself probably only arrive to do it some week(s) later, as now all my time available for this project I spend on trying to make it work for Windows sob

Haha. I feel your pain. Really I do. If you want to try running lighttpd native for _WIN32, see my win32-exp branch https://github.com/gstrauss/lighttpd1.4/tree/win32-exp

[birdofpreyru]

Hi @gstrauss , glad to see you here :) I'll give it a try.

Can you brief me, what is its state, are you aiming MinGW build with it, to what degree does it work already?

So far, I've spend a bunch of time experimenting with my fork of the main branch, learning peculiarities of Universal Windows Platform on the way. Got an impression that building it with Cygwin and launching that in a dedicated process was the only way to go. It brings in some problems and limitations, but when I tried to edit the codebase to build it with MinGW the amount of changes I had to do was scary, and I surrendered when arrived to a need of changes related to file descriptors and pipes - due to lack of deep knowledge in how they work in Linux and on Windows, I realistically thought I won't be able to make it successfully (and also thought you are probably not interested to invest your time into it).

[gstrauss]

lighttpd builds under cygwin and is available as an installable package from cygwin repositories. Most modules work.

My experimental branch is a native _WIN32 port and can be built with autotools or CMake, using MINGW or Visual Studio. It passes the lighttpd test suite, so basic functionality is known to work. There is some support for translating UTF-8 to wide char for Windows filesystems, but more is probably needed. There may be other issues and limitations, as Windows is a very limiting platform and the experimental lighttpd _WIN32 native port has not been extensively tested. My experimental branch includes the ability to install lighttpd as a Windows service. There is not much documentation, but there are comments in the code. Feedback is appreciated, though keep in mind that the lighttpd _WIN32 port should not be considered a production platform.

[gstrauss]

I posted some notes on https://wiki.lighttpd.net/DevelWin32

when I tried to edit the codebase to build it with MinGW the amount of changes I had to do was scary

Yes, Windows is very different. Not better; different. And very often not better, IMNSHO.

My lighttpd native _WIN32 port is "only" 2.5x (250%) slower serving static files than running on the same hardware on Linux, and upwards of 20x slower (2000%) running CGI, as Windows is so slow at process creation and process management.

(and also thought you are probably not interested to invest your time into it)

I do not consider Windows a production platform on which I would personally run anything exposed to the internet, and so there is a limit to additional development time I might spend on _WIN32. Non-zero, but very low priority.

As luck would have it, I was recently checkpointing my _WIN32 experiment and I also happened across this page in github search, so that's why I posted here.

[birdofpreyru]

Hey @gstrauss , I gave it a try, and it works quite good for me :) I see your concerns, but for us, within this library, the use case and priorities are very different. At least how I see it, the main scenario is to run embed http server inside a mobile app, to serve static assets to the web browser embed into the same app. It helps using web app techs inside a mobile app, reusing codebases and libraries between websites and mobile apps, etc. Thus, the performance is not that important (essentially, the load on the server is 1 client - not hundreds / thousands / ...), advanced server capabilities are not that important for now, and probably it is not really exposed to network in most cases. The uniform behavior of basic server functionality across platforms is our main priority.

So... on Windows we have to run it as a part of an Universal Windows Platform app, and because of artificial limitations imposed by UWP apps, we have to build it into a shared DLL library. Kind of similar to what I did before for Android and iOS, but with its own peculiarities. Although I should do more testing and stuff, it already seems I pulled it through, and already have a functional version of this library for Windows. The feedback I got so far for you:

• This block of code does not do well for me, it just crashes everything, unless I comment it out. As it is not essential, I haven't tried so far to debug what is wrong with it.
• The way you made server_win32.c, using the same technique you recommended me to override main() for my library entrypoints, conflicts with my code. I sure corrected my code to work fine with your windows version, but that's getting messy, as there are now multiple main() functions, overriden differently on different platforms. It would be cool to re-engineer that to have the body of current main() functions named differently, which can be then called from a small main() entrypoint, or library entry point, in my case, without relying on define pragmas to override main.
• I'd love to see your windows branch merged into the main branch already. Just to help ensuring that it does not lag too far behind the main.

[gstrauss]

There are additional limitations in UWP apps that I have not researched and have no plans to research.

You may enlighten me if you would like to propose patches. I'll review submitted patches. I suspect lighttpd's expectation of std handles in a dll in a UWP app is resulting in the crash you see.

In case my above statement was not sufficiently clear: this will not be fixed in my win32-exp branch unless someone else explains to me why this crashes and proposes an alternative. I have not set up an environment to test UWP apps and have no plans to do so.

Regarding merging the code into lighttpd master branch, the limitation there is dependent on testing. Your independent testing helps, so thank you. Between now and the end of Q2, I may do a little bit more diddling with the windows service setup code, but nothing major is planned.

If you have some more detailed concrete suggestions or prototypes for handling main() differently, I'll review them, but -- and big but -- lighttpd is first and foremost an application and will continued to give that mode and structure priority. Function calls 50 layers deep before getting to server_main_loop() is a non-starter. Right now, it is two levels on the stack, main() and server_main_loop() in the lighttpd application. Any suggestions should strive to be minimal, clean, and elegant.

Can you help me to understand how this construct is not extendible for you with a #include in the right place in server.c?

#ifdef main
    [...]
#else
    [...]
#endif

You might have to independently patch a few lines in server_win32.c. However, I do not foresee other files like server_win32.c. Windows is its own toilet bowl(s) and so I wanted to keep separate as much _WIN32 code as I could.

[gstrauss]

P.S. I think _WIN32 is off-topic for the original post in this issue. Feel free to create a separate issue and to tag me.

[gstrauss]

I pushed an (untested) change to my win32-exp branch to redefine main(). See if you like that better?

[birdofpreyru]

Hey @jacobmolby , I've just released the new library version (v0.7.1). Presumably, it should fix your build problem, this thread was originally about. When you have a moment, can you check it, and confirm whether it works for you?

[asurare]

Sorry to comment on a closed issue, but in case someone have the same problem as me (Xcode not able to find cmake event though it is installed), I had to manueally export the path, just like suggested here -> #18 (comment)

@birdofpreyru If you need me to open a new issue to track this, tell me :)

[birdofpreyru]

Hi @asurare , I'll only agree this is an issue with this library, if you confirm the Xcode itself is able to locate cmake without having its location in PATH (I mean, in some other build / build step, probably it looks up its path from some other environment variable, set by SDK, or whatever? — in such case I can update the library's build process to check that variable for possible cmake location). Otherwise, I'd say the problem is that you don't have cmake or homebrew installed correctly, to automatically have it added to PATH, and you should fix it not in the library, but appending its location to PATH in the start-up .bashrc file (or whatever it is called on macOS).

[asurare]

Hi @asurare , I'll only agree this is an issue with this library, if you confirm the Xcode itself is able to locate cmake without having its location in PATH (I mean, in some other build / build step, probably it looks up its path from some other environment variable, set by SDK, or whatever? — in such case I can update the library's build process to check that variable for possible cmake location). Otherwise, I'd say the problem is that you don't have cmake or homebrew installed correctly, to automatically have it added to PATH, and you should fix it not in the library, but appending its location to PATH in the start-up .bashrc file (or whatever it is called on macOS).

cmake is indeed accessible in a classic bash session (both sh and zsh), and is exported to the path (found in its correct location through which → /opt/homebrew/bin/cmake). I'm not sure how Xcode try to resolve the path to find these binary files, but maybe this is where there is an issue (so maybe more Xcode related). I won't have time today to explore this, but I'll explore this asap and create an issue if necessary. (And btw, ty a lot for forking and maintaining this lib, that saved me a lot of work 😄)