pkgsrc-Changes archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: pkgsrc
* On 2014-02-27 at 13:12 GMT, Ryo ONODERA wrote:
> From: Ryo ONODERA <ryo_on%yk.rim.or.jp@localhost>, Date: Thu, 27 Feb 2014
> 21:11:24 +0900 (JST)
>
> > 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.
>
> I do not know the real solution, but the following patch works for me.
I think the correct solution is this (snipped for brevity) patch to
libtool/patches/patch-ab:
-----
netbsd*)
@@ -418,10 +418,11 @@
+ hardcode_libdir_flag_spec_CXX='${wl}-rpath,$libdir'
+ hardcode_direct_CXX=yes
+ hardcode_shlibpath_var_CXX=no
++ output_verbose_link_cmd=func_echo_all
;;
*nto* | *qnx*)
-----
This directive is already used by the other BSDs, and for me produces a libtool
which is identical to one generated before the wrapper change.
Joerg, any comments?
--
Jonathan Perkin - Joyent, Inc. - www.joyent.com
Home |
Main Index |
Thread Index |
Old Index