[Gdal-dev] GDAL Manifest Changes

Tamas Szekeres szekerest at gmail.com
Fri Nov 3 20:05:14 EST 2006


Simon,

I've tested the solution and works pretty well for the C# interface.
>From the C#'s point of view it would be enough to embed this kind of
manifests only for the
root dll to be loaded first having dependencies to the CRT assembly wrapper.
However it is not harmful to embed the manifests as a resource into
each of  the corresponding dll-s and executables.

Thanks, for your work, I think we would have to make similar solutions
for the mapserver project.

Best Regards,

Tamas


2006/11/3, Simon Perkins <sy at perkins.net>:
>
> Visual Studio / makefile.vc people:
>
> I've just checked some small changes into makefile.vc, apps/makefile.vc
> and ogr/Makefile to automatically embed manifests into DLLs and EXEs, if
> they are generated. Shouldn't have any effect unless you're using VS
> 2005. I also removed the lines I added a few months ago to install
> manifest files into the install directories for the install target,
> since this is no longer necessary. Manifest files are also cleaned up by
> the clean target.
>
> This should eliminate some mysterious "MSVCR80.DLL not found" problems
> you may encounter when linking against GDAL built using VS 2005.
>
> Basically, every DLL and EXE target now has an additional line that
> looks something like:
>
> if exist $(SOME_DLL).manifest mt -manifest $(SOME_DLL).manifest -outputresource:$(SOME_DLL);2
>
> or
>
> if exist $(SOME_EXE).manifest mt -manifest $(SOME_EXE).manifest -outputresource:$(SOME_EXE);1
>
>
> Note that this is a subset of the solution found here:
>
> http://msdn2.microsoft.com/en-us/library/ms235591.aspx
>
> That solution has a lot of extra bells and whistles to enable incremental linking. But full linking doesn't seem to take very long anyway, so I didn't bother including that stuff.
>
>
> Please let me know if you encounter any problems.
>
> Cheers,
>
> Sy
>
>
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>



More information about the Gdal-dev mailing list