[Ffmpeg-devel] [PATCH] Build Darwin dynamic/shared libraries

[Michael Niedermayer]

Hi

On Thursday 14 July 2005 12:27, Dan Villiom Podlaski Christiansen wrote:
> Michael Niedermayer wrote:
> > Hi
> >
> > On Wednesday 13 July 2005 14:06, Dan Villiom Podlaski Christiansen wrote:
> > [...]
> >
> >> 3) initialise 3 common variables in libavcodec/msmpeg4.c, to not make
> >> ld(1) complain about common storage. I discussed this with a GCC hacker
> >> on IRC, and there was a reason why this was necessary, but I didn't
> >> quite understand what it was ;)
> >
> > thats a bit unprecisse, is it needed by gcc? a specific version? the c
> > standard? is it a warning or an error?
> > if its needed by the c standard its ok obviously, if its not and just a
> > warning its rejected, ...
>
> It was about the semantics of Mach-O binaries. If the variables weren't
> initialised, they would be put in a section of the binary which couldn't
> be referenced by other modules in the library. There were two possible
> solutions to this: Either the library could be built as a single module,
> which IIRC he said was a bit risky, or the variables could be
> initialised. Initialising the variables struck me as the cleanest
> solution as it's merely stating explicitly what would happen anyway.

something is wrong here, global variables must be initalized to 0 accoriding 
to the c standard, now if we initalize them explicitly to 0 that doesnt change
anything and if gcc outputs different code here thats very odd, i would have
expected gcc to be able to optimize this away
without knowing gccs internals i feel that assuming that future versions of
gcc will not optimize this away is risky furthermore such things would need
to be documented it cant be expected that the reader knows that a global x=0;
is needed by gcc-darwin-mach-o


>
> >> 4) make the vhooks Mach-O bundles rather than libraries.
> >> 5) add support for a ${DESTDIR} environment variable to force
> >> installation into another path than the root. I found it quite useful.
> >
> > we have bindir, libdir, mandir and prefix isnt that enough?
>
> I'm afraid not, since $libdir gets hard-coded into the libraries. The

then why not add another variable for that hardcoded dir? hardcoded_libdir or
so? 

putting DESTDIR before every occurance of libdir, bindir and mandir is not 
acceptable


[...]

>
> > iam also not too happy about all the ifeq ($(CONFIG_DARWIN),) in the
> > makefiles, this should be in configure IMHO
>
> For many of these, there is no other simple solution. The Mach-O linker
> is very different from the ELF linker, and the library naming
[...]

> ifeq ($(CONFIG_DARWIN), yes)
> SHFLAGS+=-install_name $(libdir)/$(SLIB) -compatibility_version 
$(SLIB_VERSION) -current_version $(SLIB_VERSION)
> endif

[...]

-- 
Michael