dmik
commented
8 years ago I don't think we should do that, for the following reasons:
- Standard autoconf doesn't do any
mmap.aor-lmmapchecks, it assumesmmap()is present in the standard libc which can be affected by LIBS (as LIBS is used when building configure tests). In fact, LIBS is how OS/2 injects mmap.a into the standard configure checks (and eventuallyinto the build) but this is completely OS/2-specific. Since projects using mmap.a (through LIBS=-lmmap) need to be rebuilt anyway in order to use the new mmap implementation from LIBCx, one may easily replace-lmmapwith-lcxin LIBS in .spec files (or any other OS/2-specific build scripts) of these projects while rebuilding them. This will explicitly express the change from the old mmap.a implementation to the new one provided by LIBCx since they are incompatible (and that's why we also don't provide a forwarder frommmap.dlltolibcxN.dll. - In theory there may be projects that depend on the old mmap implementation and don't want to use the new one. Given a separate mmap.a/mmap.dll (and the respective yum packages) they will still be able to use the old version if this is vital for them.
So I'm closing this as "won't fix" with a recommendation to replace -lmmap to -lcx in the relative scripts when rebuilding.
@ydario if you have strong objections, please feel free to reopen the issue and mention them.
since libcx provides memory mapping support, it should ship a mmap.a for compatibility with existing builds. Also many scripts are checking for mmap.a to verify if it is enabled.