Upgrade Perl 5.40 to 5.42: /usr/local/include/crypt.h:73:8: error: redefinition of 'crypt_data'

[SevenDayz]

How does this help?

1. New FreeBSD installation (or new BE and pkg delete all packages).
2. Build and install lang/perl5.42
3. Build and install security/libxcrypt
4. Try to rebuild lang/perl5.42

Probably, it's a magic?

I have this problem on an old FreeBSD installation.

What does BE mean?

 

[T-Aoki]

Well, is there any mention about the security/libxcrypt port?

No, not DIRECTLY described.
But it's one of the dependencies of lang/perl*, so it's SURELY and ABSOLUTELY included.

 

[zapata]

BE = Boot Environment ... I just described a way how to easily reproduce this issue. In most cases build issues like this get fixed.

 

[SevenDayz]

Maybe someone should open a PR if perl 5.4X fails to build if security/libxcrypt is installed.

By the way, none of the 11 ports at the post #20 have a dependency on the security/libxcrypt port.

 

[SevenDayz]

No, not DIRECTLY described.
But it's one of the dependencies of lang/perl*, so it's SURELY and ABSOLUTELY included.

Please clarify: are the security/libxcrypt port or a libcrypt library the dependencies of lang/perl?

 

[T-Aoki]

Possibly there were some ports depending on security/libxcrypt as a NON DEFAULT dependency, but maybe already deleted.

 

[SevenDayz]

BE = Boot Environment ... I just described a way how to easily reproduce this issue. In most cases build issues like this get fixed.

OK I'll try this.

 

[T-Aoki]

Please clarify: are the security/libxcrypt port or a libcrypt library the dependencies of lang/perl?

AT LEAST NOT AT ALL NOW. IN REVERSE. At least by default.
What you can see as dependencies / depending upon it at FreshPorts is default ones only. NON DEFAULT ONES VIA OPTIONS NOR FLAVORs ARE NOT AT ALL LISTED!

 

[zapata]

OK I'll try this.

Sorry, I mean build issues like this get fixed by the port maintainer.

 

[zapata]

Perl uses libcrypt.so.5 from base. Maybe perl should not check for crypt.h in Configure.

: see if this is a crypt.h system
set crypt.h i_crypt
hdrs="$i_systypes sys/types.h define stdio.h $i_crypt crypt.h"

 

[SevenDayz]

Possibly there were some ports depending on security/libxcrypt as a NON DEFAULT dependency, but maybe already deleted.

Now I can't say for certain.

 

[T-Aoki]

Now I can't say for certain.

Yes, it's hard to track, as defaults changes from time to time, and config screen does NOT appear when defaults changes. Appears only when something new is ADDED. Annoying.
And this sometimes causes hard to track build issues, as current default is tested by maintainer(s) and confirmed OK, but as maintainers / committers are mostly 100% volunteers working on their free time, confirming for non-default option cannot be forced.

 

[SevenDayz]

AT LEAST NOT AT ALL NOW. IN REVERSE. At least by default.
What you can see as dependencies / depending upon it at FreshPorts is default ones only. NON DEFAULT ONES VIA OPTIONS NOR FLAVORs ARE NOT AT ALL LISTED!View attachment 25756

Sorry, I can't see this there perl5.42

 

[T-Aoki]

Sorry, I can't see this there perl5.42

See via security/libxcrypt.
Or click at the downward triangle here

to expand the whole list of "required by: for Build".

 

[zapata]

Yes, security/libxcrypt requires perl but perl doesn't require security/libxcrypt.

- the perl port should not check for crypt.h (don't define I_CRYPT) and use libcrypt.so from base (/lib) not /usr/local/lib.
- library and include files of the libxcrypt port should be renamed (xcrypt.h, libxcrypt.so). Patch other ports that really need it (I couldn't find one)
- or simply remove the port (from the tree)

Maybe perl@ has an easy fix.

 

[T-Aoki]

Yes, security/libxcrypt requires perl but perl doesn't require security/libxcrypt.

- the perl port should not check for crypt.h (don't define I_CRYPT) and use libcrypt.so from base (/lib) not /usr/local/lib.
- library and include files of the libxcrypt port should be renamed (xcrypt.h, libxcrypt.so). Patch other ports that really need it (I couldn't find one)
- or simply remove the port (from the tree)

Maybe perl@ has an easy fix.

Maybe (currently nonexistent) /usr/libdata/crypt.pc is wanted?