All the Perl that's Practical to Extract and Report

perl Configure decides to use string.h?

jdavidb on 2006-07-07T18:13:53

Anyone know real quick what causes perl's Configure process to decide to emit the following line?

Using  instead of .

I think it is a mistake in our case, because string.h is C++. It's very definitely causing a compilation failure on a new machine that's probably been misconfigured. :)

Update: Never mind, this seems to be appropriate behavior, but this inappropriate system has a C++ /usr/local/include/string.h which is interfering with the compiler's ability to find the correct, C, /usr/include/string.h. I hope nobody notices that we moved /usr/local/include to /usr/local/include.old

is ANSI (or SysV), is BSD

jhi on 2006-07-07T20:36:27

I saw your "never mind", but thought to comment anyway. has memcpy() while has bcopy(), and so forth.

Re: is ANSI (or SysV), is BSD

jhi on 2006-07-08T17:45:02

> has memcpy() while has bcopy(), and so forth.

Oh, bugger.

<string.h> has memcpy() while <strings.h> has bcopy(), and so forth.

Re: is ANSI (or SysV), is BSD

jdavidb on 2006-07-10T13:50:20

Eek. So I should pretty much never see strings.h in the environment I'm in.

This turned out fun as my sysadmin moved /usr/local/include completely out of the way to compile, and then I got a phone call Friday afternoon after I left the office because that broke a lot of things. :)