this is to force pkg_add -u to pick them up because moving to PIE does change
these files but since there are no library bumps, the package signature stays
the same.
there are probably others, these are just ones I've run into. not a great
fix, and needs to be repeated when other arch move, but it's the simplest low
impact fix and I'm fed up with "relocation R_X86_64_32S can not be used
when making a shared object; recompile with -fPIC"
this is to force pkg_add -u to pick them up because moving to PIE does change
these files but since there are no library bumps, the package signature stays
the same.
there are probably others, these are just ones I've run into. not a great
fix, and needs to be repeated when other arch move, but it's the simplest low
impact fix and I'm fed up with "relocation R_X86_64_32S can not be used
when making a shared object; recompile with -fPIC"
- Sync WANTLIB
- Remove use of CONFIGURE_SHARED since this is SHARED_ONLY anyway
- Remove unnecessary patching for the autoconf script and pkg-config files
From giovanni@
- Enable the PostScript plugin
- Update distinfo
ok giovanni@
(CUdeviceptr)((uchar*)mem.device_pointer + offset)
-> error: cast from 'ccl::uchar*' to 'CUdeviceptr' loses precision
tried whacking it with some obvious hacks but failed.
* A number of security issues have been resolved, including CVE-2012-3401.
* Accessor functions for TIFF field information have been added to
support functionality which was available in libtiff 3.9.X.
ok jasper@
ports, for the ports that are built both on ruby 1.8 and ruby 1.9,
switch the category Makefiles to explicitly list the ruby18 FLAVOR
instead of the ruby19 FLAVOR.
Also, for home_run, fastri, and fastercsv, explicitly build only the
ruby 1.8 version of the port. These libraries can run on ruby 1.9, but
it doesn't make sense to build a ruby 1.9 version by default.
