Created attachment 36270 [details] [PATCH] server/Makefile.in: handle separate APR_INCLUDE_DIR/APU_INCLUDE_DIR If APR_INCLUDEDIR and APU_INCLUDEDIR point to different directories, but for example APU_INCLUDEDIR contains both the apr headers and apu headers, the "export_files" file will contain duplicate header files, causing the exports.c file to contain duplicate definitions, making the build fail. The attached patche fixes that by making sure we only use the apr headers from APR_INCLUDEDIR and the apu headers from the APU_INCLUDEDIR.
"If APR_INCLUDEDIR and APU_INCLUDEDIR point to different directories, but for example APU_INCLUDEDIR contains both the apr headers and apu headers" That's seems like a broken APR/APR-util installation, how did it get in that state?
Thanks for calling it "broken" :-) I am working on the Buildroot project (http://buildroot.org) a tool that builds a Linux system from source for embedded systems, using cross-compilation. As part of this, I am currently working on moving from a global compiler sysroot design (where all libraries/headers are installed in a common location) to a per-package compiler sysroot design (where the compiler sysroot only contains the libraries/headers of the dependencies of that package). With this design, when I build apr, the compiler sysroot initially contains just the C library and headers. After apr is built, it contains C library + apr. Then, we build apr-util, we bring the apr compiler sysroot (C library + apr), build apr-util and install it. Then, we build apache, we bring the apr-util compiler sysroot (C library + apr-util + apr) and build apache. The thing is that APR_INCLUDEDIR will point to the compiler sysroot of apr (which contains just the apr headers) and APU_INCLUDEDIR will point to the compiler sysroot of apr-util (which contains both the apr and apr-util headers). This is how we end up in this situation, which I don't think is really "broken".