Re: CVS commit: pkgsrc

[Ryo ONODERA <ryo_on%yk.rim.or.jp@localhost>]

From: Jonathan Perkin <jperkin%joyent.com@localhost>, Date: Thu, 27 Feb 2014 
11:55:43 +0000

> * On 2014-02-27 at 11:07 GMT, Ryo ONODERA wrote:
> 
>> From: "Jonathan Perkin" <jperkin%netbsd.org@localhost>, Date: Wed, 26 Feb 
>> 2014 10:40:46 +0000
>> 
>> > Module Name:       pkgsrc
>> > Committed By:      jperkin
>> > Date:              Wed Feb 26 10:40:46 UTC 2014
>> > 
>> > Modified Files:
>> >    pkgsrc/devel/libtool-base: Makefile
>> >    pkgsrc/devel/libtool-fortran: Makefile
>> >    pkgsrc/mk/wrapper: scan
>> > 
>> > Log Message:
>> > Remove special handling of -v in the wrappers.
>> > 
>> > This was originally introduced to work around some behaviour in the
>> > libtool build, however these days it is actively harmful for a number of
>> > packages, where removing additional arguments when -v is present on the
>> > command line can break ABI detection (notably in CMake packages).
>> > 
>> > Instead, filter out any references to BUILDLINK_DIR from the libtool
>> > scripts, as that should do the same job.
>> > 
>> > Retain the ability to run the 'scan' wrapper script, as it can be useful
>> > in certain cases, and is required to support the scan-libtool script
>> > anyway.
>> 
>> With this change (especially mk/wrapper/scan), devel/libtool-base
>> under NetBSD/amd64 6.99.32 have been broken.
>> pkg/bin/libtool has
>> 
>> postdeps="-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc"
>> 
>> line in C++ part. And textproc/hunspell cannot create shared library
>> because it cannot find libgcc.so (NetBSD has no libgcc.so).
> 
> Hmm, I see a similar change in the generated libtool on my NetBSD
> 6.1.3 VM, however I do not see the same failure as a result of it.
> 
> The full diff is:
> 
>   @@ -10227,10 +10227,10 @@
>   
>    # Dependencies to place before and after the objects being linked to
>    # create a shared library.
>   -predep_objects=""
>   -postdep_objects=""
>   +predep_objects="/usr/lib/crti.o /usr/lib/crtbeginS.o"
>   +postdep_objects="/usr/lib/crtendS.o /usr/lib/crtn.o"
>    predeps=""
>   -postdeps=""
>   +postdeps="-lstdc++ -lm -lgcc -lc -lgcc"
>   
>    # The library search path used internally by the compiler when linking
>    # a shared library.
> 
> Did something change in current to affect this?  I don't have a
> current system to test on, unfortunately.

My NetBSD/amd64 6.1 test enviroment has same problem.
Only static library is built, there is no error, it is warning like this.

*** Warning: linker path does not have real file for library -lgcc.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libgcc and none of the candidates passed a file format test
*** using a regex pattern. Last file checked: /usr/lib/libgcc.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Please see the output of your ls /usr/pkg/lib/libhunspell* .

Thank you.

--
Ryo ONODERA // ryo_on%yk.rim.or.jp@localhost
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3