[GRASS-dev] discussion: replacing ps.map
Glynn Clements
glynn at gclements.plus.com
Fri Apr 6 10:29:45 EDT 2007
William Kyngesburye wrote:
> >> I'm having a problem building libraster now. I get a bunch of
> >> multiple definitions errors between the linked pngdriver and psdriver
> >> when linking the raster library.
> >>
> >> _true_color
> >> _height
> >> _width
> >> _init_color_table
> >
> > Can you find out whether the Mac linker has an option to ignore
> > duplicate symbols (at least for the case where none of the symbols are
> > actually being imported)?
> >
> > If it does, adding that switch to the definition of SHLIB_LD in
> > SC_CONFIG_CFLAGS (in aclocal.m4) is the appropriate solution.
> >
> > If it doesn't, I can give these functions/variables unique names, but
> > that's really just a workaround; this issue is likely to crop up again
> > in the future.
>
> The flag to manually make them warnings is -multiply_defined warning
> (or suppress). But it's really an effect of using a flat namespace.
> -flat_namespace (and -fno-common) might be a holdover from the early
> Mac days building GRASS, when there were probably issues. The
> default on OSX, since 10.1, is a two-level namespace, where multiply-
> defined symbols are a warning by default.
>
> I removed -flat_namespace from my SHLIB_LD in platform.make (quick-n-
> dirty hack). The multiply-defined symbols don't break the raster
> library linking now.
I'll change that in CVS.
> But instead I have an undefined symbol in the
> display library:
>
> ld: Undefined symbols:
> _PS_Driver referenced from libgrass expected to be defined in /
> Applications/GRASS-6.3.app/Contents/Resources/lib/
> libgrass_psdriver.dylib
It appears to be using the version in /Applications rather than the
local version.
This suggests that the linker needs something similar to the
-Wl,-rpath-link switch which is used on Linux:
CC_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}'
This tells the linker where to look for dependencies.
Without that, you will need to ensure that the lib directory of any
installed version of GRASS isn't searched automatically (e.g. due to
$DYLD_LIBRARY_PATH or similar).
> (that 'libgrass' got truncated, it's really libgrass_display - it's
> an intentional quirk of the OSX linker)
It's libgrass_raster which actually references PS_Driver().
Linking libgrass_raster will find the correct version of
libgrass_psdriver due to the -L switches. But when linking
libgrass_display against libgrass_raster, the -L switches will only
tell it where to find -lraster itself; its dependencies will normally
be looked for using the loader's settings ($DYLD_LIBRARY_PATH etc).
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list