Would this be a good time to fix this warning?
jpeglib.lib(jerror.obj) : MSIL .netmodule or module compiled with /GL
found; restarting link with /LTCG; add /LTCG to the link command line to
improve linker performance
Thanks
On Tue, Nov 29, 2016 at 10:30 PM, Nat Goodspeed wrote:
> On Nov 29,
I'd like to fix that too.
Is it just a question of add /LTCG to the jpeglib link command? I see
that's done via an nmake makefile and then build via a .sln but I think I
see where to add that command.
On Wed, Nov 30, 2016 at 5:53 AM, Nicky Perian wrote:
> Would this be a good time to fix this
On Wed, Nov 30, 2016 at 4:04 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:
Is it just a question of add /LTCG to the jpeglib link command? I see
> that's done via an nmake makefile and then build via a .sln but I think I
> see where to add that command.
>
I think we decided back wh
>> Is it just a question of add /LTCG to the jpeglib link command?
I tired that and it didn't change anything.
On Wed, Nov 30, 2016 at 3:04 PM, Callum Prentice (Callum) <
cal...@lindenlab.com> wrote:
> I'd like to fix that too.
>
> Is it just a question of add /LTCG to the jpeglib link command?
Disregard, It was a viewer cmake for llimagej2coj
that did not work.
${OPENJPEG_LIBRARIES}
)
+if (WINDOWS)
+ set_target_properties(
+llimagej2coj
+PROPERTIES
+LINK_FLAGS "/MANIFEST:NO /SAFESEH:NO /LTCG /NODEFAULTLIB:LIBCMT"
+LINK_FLAGS_DEBUG "/MANIFEST:NO /SAFESEH:NO /NOD
On 11/30/2016 4:11 PM, Nat Goodspeed wrote:
>
> I think we decided back when switching to VS 2013 that /GL and /LTCG
> didn't add enough value for us to bother with them. I think the
> expedient fix would be to remove /GL from jpeglib.
I'll be the grumpy engineer and ask that 00-COMPILE-LINK-RUN.t
I'm working with Nat Linden on the 64 bit viewer build and we've been
encountering an odd error - A number of projects in 64 bit only
configurations have an entry for "Force Includes" files set to XED:NO.
Nothing on Google so we were stumped for a while but eventually tracked it
down to a number of
It’s not needed. We dropped it in Alchemy when adding 64-bit support, and it
continues to run fine. /FIXED:NO just ensures that code can be position
independent. Maybe at some point this was needed a long time ago for apr
hijinks or Windows98 compatibility or something of that nature, but you ca
Thanks so much for the speedy reply Cinder. I hoped that was the case and the
build seems okay without it.
The other perplexing one is for the winmm_shim project. For 64 bit builds it
fails with a bunch of unresolved externals which look to be related to MMX
intrinsic maybe. Not at my computer
We nuked that whole project and set volume directly on Windows using
waveOutSetVolume(HWAVEOUT, DWORD).
https://bitbucket.org/alchemyviewer/alchemy/commits/b3e54a075de4440390bb1be8c9f73bfd94053a01
The shim is only needed up to XP and is completely unnecessary with the
availability of WASAPI in V
Great. I had an idea that was the case. Thanks again Cinder.
On Wed, Nov 30, 2016 at 6:30 PM, Cinder Roxley
wrote:
> We nuked that whole project and set volume directly on Windows using
> waveOutSetVolume(HWAVEOUT, DWORD).
> https://bitbucket.org/alchemyviewer/alchemy/commits/
> b3e54a075de44403
11 matches
Mail list logo
