#895 closed defect (remind)
Multiply-defined libraries on Mac OS X dylib compilation
| Reported by: | Michael Wood-Vasey | Owned by: | eugene |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | Ohana | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Mac OS X dylib is pretty picky about building the dylib libraries with no duplicated/conflicting names. I present the following fix to the problem I outline further below.
I think I've tracked down the issue and solution for the multiply-defined _DVOTableFormat and _DVOTableMode. These two things are 'enum's defined in 'dvo.h' ('Ohana/src/libdvo/include/dvo.h') which is included by 'kapa.h' which is included in a few of the files in 'psphot/src' ('psphotRadialPlot.c', 'psphotSummaryPlots.c', 'psphotVersion.c'). I changed lines 17 & 20 in 'dvo.h' to put in an 'extern' in front of the two enum definitions and then 'make clean' in Ohana and in 'psphot' and 'psconfigure; make; make install'.
The problem
I've run into the following problem in IPP 2.2 in combining libraries into .dylib files in Mac OS X.
gcc -std=gnu99 -dynamiclib ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o .libs/libpsphot.0.0.0.dylib .libs/libpsphot_la-psphotErrorCodes.o .libs/libpsphot_la-pmFootprint.o .libs/libpsphot_la-psphotVersion.o .libs/libpsphot_la-psphotModelGroupInit.o .libs/libpsphot_la-psphotMaskReadout.o .libs/libpsphot_la-psphotDefineFiles.o .libs/libpsphot_la-psphotReadout.o .libs/libpsphot_la-psphotImageMedian.o .libs/libpsphot_la-psphotFindPeaks.o .libs/libpsphot_la-psphotSourceStats.o .libs/libpsphot_la-psphotRoughClass.o .libs/libpsphot_la-psphotBasicDeblend.o .libs/libpsphot_la-psphotChoosePSF.o .libs/libpsphot_la-psphotGuessModels.o .libs/libpsphot_la-psphotFitSourcesLinear.o .libs/libpsphot_la-psphotBlendFit.o .libs/libpsphot_la-psphotReplaceUnfit.o .libs/libpsphot_la-psphotApResid.o .libs/libpsphot_la-psphotMagnitudes.o .libs/libpsphot_la-psphotSkyReplace.o .libs/libpsphot_la-psphotEvalPSF.o .libs/libpsphot_la-psphotEvalFLT.o .libs/libpsphot_la-psphotSourceFits.o .libs/libpsphot_la-psphotRadiusChecks.o .libs/libpsphot_la-psphotSortBySN.o .libs/libpsphot_la-psphotOutput.o .libs/libpsphot_la-psphotGrowthCurve.o .libs/libpsphot_la-psphotFakeSources.o .libs/libpsphot_la-psphotModelWithPSF.o .libs/libpsphot_la-psphotExtendedSources.o .libs/libpsphot_la-psphotPetrosian.o .libs/libpsphot_la-psphotIsophotal.o .libs/libpsphot_la-psphotAnnuli.o .libs/libpsphot_la-psphotKron.o .libs/libpsphot_la-psphotKernelFromPSF.o .libs/libpsphot_la-psphotPSFConvModel.o .libs/libpsphot_la-psphotModelTest.o .libs/libpsphot_la-psphotFitSet.o .libs/libpsphot_la-psphotSourceFreePixels.o .libs/libpsphot_la-psphotSummaryPlots.o .libs/libpsphot_la-psphotMergeSources.o .libs/libpsphot_la-psphotLoadPSF.o .libs/libpsphot_la-psphotReadoutCleanup.o .libs/libpsphot_la-psphotSourcePlots.o .libs/libpsphot_la-psphotRadialPlot.o .libs/libpsphot_la-psphotDeblendSatstars.o .libs/libpsphot_la-psphotMosaicSubimage.o .libs/libpsphot_la-psphotMakeResiduals.o .libs/libpsphot_la-psphotSourceSize.o .libs/libpsphot_la-psphotAddNoise.o -install_name /Users/Shared/PS1/code/ipp-2.2default.darwin/lib/libpsphot.0.dylib -Wl,-compatibility_version -Wl,1 -Wl,-current_version -Wl,1.0
ld: multiple definitions of symbol _DVOTableFormat
.libs/libpsphot_la-psphotVersion.o definition of _DVOTableFormat in section (DATA,common)
.libs/libpsphot_la-psphotModelGroupInit.o definition of _DVOTableFormat in section (DATA,common)
ld: multiple definitions of symbol _DVOTableMode
.libs/libpsphot_la-psphotVersion.o definition of _DVOTableMode in section (DATA,common)
.libs/libpsphot_la-psphotModelGroupInit.o definition of _DVOTableMode in section (DATA,common)
.libs/libpsphot_la-psphotMaskReadout.o definition of _DVOTableFormat in section (DATA,common)
.libs/libpsphot_la-psphotMaskReadout.o definition of _DVOTableMode in section (DATA,common)
.libs/libpsphot_la-psphotDefineFiles.o definition of _DVOTableFormat in section (DATA,common)
.libs/libpsphot_la-psphotDefineFiles.o definition of _DVOTableMode in section (DATA,common)
Change History (2)
comment:1 by , 19 years ago
| Resolution: | → remind |
|---|---|
| Status: | new → closed |
comment:2 by , 19 years ago
Here's a thread (last entry first) I had with Robert Lupton on the issue:
From: rhl@…
Subject: Re: [Ps-ipp-users] Multiply-defined symbols in psphot libraries
Date: August 1, 2007 9:36:08 EDT
To: Michael Wood-Vasey
Oh, I see. The problem isn't the enum definition but that Gene's
declaring an object of type enum.
Sounds like you did exactly the right thing (I assume that there's
an actual declaration somewhere too).
Sorry to butt in.
R
From: Michael Wood-Vasey
Subject: Re: [Ps-ipp-users] Multiply-defined symbols in psphot libraries
Date: August 1, 2007 9:29:15 EDT
To: rhl@…
On Aug 1, 2007, at 9:21, Robert Lupton the Good wrote:
I don't keep this checked out, but is the problem that a single
file's being included twice? There should be an include guard
at the top of the file (#if !defined(KAPA_H) ...)
I don't think so. A bunch of libraries that each include the 'dvo.h' file are compiled separately. Then they are combined into a single library. At this point the linker doesn't know how to treat these multiple definitions of the same thing. In this case it's just some enum definitions and it may be that other linkers just go ahead and put these definitions together.
- Michael
From: rhl@…
Subject: Re: [Ps-ipp-users] Multiply-defined symbols in psphot libraries
Date: August 1, 2007 9:21:17 EDT
To: Michael Wood-Vasey
I don't keep this checked out, but is the problem that a single
file's being included twice? There should be an include guard
at the top of the file (#if !defined(KAPA_H) ...)
R

interesting. I'm not sure I really understand this. there are actually three classes of enum-s in that file. two are defined (the ones you fixed) like this:
enum {values...} Name;
two are defined like this, and apparently don't cause an error for you:
enum {values....};
two others are defined like this, and also don't cause problems:
typedef enum {values....} Name;
so apparently some versions of gcc are treating the first format as defining a local symbol which does not conflict, but others are more careful.
in any case, I think I should change all three of these enum-s to be typedefs with specified names.
I've done this, and it will be in the next release.