enable shared lib support in linux for lua

gyp/images.gyp

Index: gyp/images.gyp
diff --git a/gyp/images.gyp b/gyp/images.gyp
index df220265fb867ea42ee69c701c2a629bdfae8442..2b20d26c69bcbf74e3adc206cacd0520e7e38a19 100644
--- a/gyp/images.gyp
+++ b/gyp/images.gyp
@@ -106,9 +106,6 @@
           # our code that calls it.
           # See http://code.google.com/p/gyp/wiki/InputFormatReference#Dependent_Settings
           'link_settings': {
-            'sources': [
-              '../src/images/SkImageDecoder_libpng.cpp',

[djsollen, 2013/06/12 17:35:46]

why did we need to remove this?

[Zach Reizner, 2013/06/12 17:42:40]

This file is already included above. Sourcing it twice works fine for static lib
builds, but causes multiple definition errors for the shared lib version.

[bungeman-skia, 2013/06/12 19:16:55]

This is slightly bizarre. What this (to be deleted) block is actually doing is
forcing shared objects (shared_library and executable) which depend on this
target to also compile SkImageDecoder_libpng.cpp into themselves directly. I
imagine this was done because the SkImageDecoder discovers decoders after
linking. It is possible there is no reference directly to a decoder so the
linker simply doesn't link the decoder in, as the symbol appears to be unused.
This block seems to say 'I know that, oops, just compile in the decoder.' We now
have better means of keeping the decoders around, so all blocks like this
('sources' inside 'link_settings') should be removed. If this causes something
to break, talk to Leon about fixing it.

This is causing an issue with shared_library targets since the shared_library
target has a copy of the decoder and this static_library also has a copy. The
linker doesn't know which to use. In the executable case, I believe that since
the symbol is already resolved in the executable itself, the linker never
considers the symbol in the static_library.

-            ],
             'libraries': [
               '-lgif',
               '-lpng',