This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

#9523 deals with a similar issue due to the fact that header files are installed in the library dir, maybe one could combine a fix for both.

Bernhard Schommer (2020/06/04 15:16 +0000):
#9523 deals with a similar issue due to the fact that header files are installed in the library dir, maybe one could combine a fix for both.
Do you really mena .h files? From what I can see in runtime/Makefile those seem to be installed in $(INSTALL_INCDIR)...

The Problem is that the $(INSTALL_INCIDIR) is equivalent to $(LIBDIR). Currently ocamlopt adds a -I $(LIBDIR) to the call to the C compiler and as described in issue #9523 there is a C++ standard header version that clashes with the file VERSION, at least for a case insensitive file systems (such as windows).

If you split the install directories of the binaries and libraries one could additionally change the way the includes are installed, but I'm unsure if that would be a practical solution.

On the other hand if the binaries are no longer installed in LIBDIR one could argue that just not installing VERSION would fix #9523. Then the only files which could clash are the libraries files which are unlikely to be used as header names, in contrast to for example expunge which might be used as header name.

I'll have to investigate whether autoconf provides support for header directories as it does for library directories. Not sure.

I think it does as @includedir@ but adding support for this might result in problems if one manually invokes the C compiler and uses for $(ocamlc -where) for adding the include path as it is currently recommended in the manual.

adding support for this might result in problems if one manually invokes the C compiler and uses for $(ocamlc -where) for adding the include path as it is currently recommended in the manual.

I was about to write exactly the same thing. We could un-recommend this usage in the manual, but a lot of makefiles use it in the wild. I think we can find a different solution for #9523.

adding support for this might result in problems if one manually invokes the C compiler and uses for $(ocamlc -where) for adding the include path as it is currently recommended in the manual.

I was about to write exactly the same thing. We could un-recommend this usage in the manual, but a lot of makefiles use it in the wild. I think we can find a different solution for #9523.

After thinking about this a little more I would argue that if this issue is fixed, i.e. the binaries are no longer installed in LIBDIR, it would suffice to just not install the file VERSION to fix #9523.

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

As far as I can tell the problem is still there.
However the solution might be to stop installing these executables completely.
expunge is used to create the toplevel, but doesn't need to be installed (I don't know about other toplevels, but utop at least doesn't rely on it).
I don't even know what extract_crc is used for. It appears to have been present since 1995, but I can't find a single use of it anywhere. I guess it was probably used for debugging before ocamlobjinfo was introduced.

However the solution might be to stop installing these executables completely.

Good lateral thinking!

expunge is used to create the toplevel, but doesn't need to be installed

I thought ocamlmktop might use expunge, but it does not and apparently never did. Caml Light's camlmktop did use expunge, which might explain why expunge is still installed?

I don't even know what extract_crc is used for.

It was used in conjunction with a function from the Dynlink module that was removed a long time ago: 5e152f7 .

Just for the reference I thought utop might be using the expunge binary but it seem it has its own version.