Perl ldflags - packaging bug, upstream bug, or weird feature?
Gerrit P. Haase
Tue Oct 4 18:57:00 GMT 2005
Max Bowsher wrote:
> $ fgrep -- '-L/usr/local/lib' /usr/lib/perl5/5.8/cygwin/Config_heavy.pl
> lddlflags=' -s -L/usr/local/lib'
> ldflags=' -s -L/usr/local/lib'
> ldflags_nolargefiles=' -s -L/usr/local/lib'
> The above shows the presence of -L/usr/local/lib in the packaged perl
> installation config vars.
> This is a problem, because when compiling Perl extensions, it places
> /usr/local/lib at the front of the library search path, taking
> precedence over any other paths that the Makefile.PL may take care to
> specify. This is bad, because /usr/local/lib may contain old/incorrect
> versions of libraries which get found instead of the libraries the
> Makefile.PL attempted to point to with explicit -L options.
But this is the deeper sense of placing it in front of the search path,
so user installed libraries may be used instead of system wide. If you
have old or broken libraries in /usr/local, just remove them. Usually
you install your own (more up to date) versions in /usr/local so you
can benefit from new features when building extensions locally.
> I don't know enough about the perl build process to know where that
> option is coming from - I'm hoping someone can tell me whether the
> presence of those harmful -L/usr/local/lib options is a packaging bug,
> an upstream bug, or a weird feature.
It is a default option. I see that this is not the best for
maintainers. As a workaround you may patch your perlld wrapper.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin