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