Shared libraries generated in different locations

[GoogleCodeExporter]

The XCode and Visual Studio generators build shared libraries right next to 
the executables (in the configuration directory, e.g. xcodebuild/Debug).

Linux (both Make and SCons) build shared libraries next to the static 
libraries (e.g. in sconsbuild/Debug/lib).  Either make this consistent or 
document it as a difference in how the underlying OS needs to be handled.

Original issue reported on code.google.com by sgk@chromium.org on 7 Aug 2009 at 12:00

[GoogleCodeExporter]

Original comment by sgk@chromium.org on 7 Aug 2009 at 12:00

[GoogleCodeExporter]

Original comment by sgk@chromium.org on 21 Oct 2009 at 5:31

• Changed state: Accepted
• Added labels: Consistency

[GoogleCodeExporter]

Issue 74 has been merged into this issue.

Original comment by sgk@chromium.org on 21 Oct 2009 at 5:59

[GoogleCodeExporter]

Would be nice to fix this. I hit this and have to look for workarounds on linux.

Original comment by nirnimesh@chromium.org on 11 May 2010 at 6:31

[GoogleCodeExporter]

I think this is perhaps resolved: shared_library is used internally by gyp so 
other pieces shouldn't rely on their location, while loadable_module writes 
into product_dir.

Original comment by evan@chromium.org on 26 May 2011 at 10:18

• Changed state: Fixed

[GoogleCodeExporter]

This bug is referenced from ffmpeg.gyp:

          'conditions': [
            ['OS=="linux" or OS=="freebsd" or OS=="openbsd" or OS=="solaris"', {
              'copies': [
                {
                  # On Make and Scons builds, the library does not end up in
                  # the PRODUCT_DIR.
                  #
                  # http://code.google.com/p/gyp/issues/detail?id=57
                  #
                  # TODO(ajwong): Fix gyp, fix the world.
                  'destination': '<(PRODUCT_DIR)',
                  'files': ['<(SHARED_LIB_DIR)/<(SHARED_LIB_PREFIX)ffmpegsumo<(SHARED_LIB_SUFFIX)'],
                },
              ],
            }],
          ],

So maybe it's not fixed?

chrome_dll.gypi has:

              'copies': [
                {
                  'destination':
                      '<(PRODUCT_DIR)/$(CONTENTS_FOLDER_PATH)/Libraries',
                  'files': [
                    # TODO(ajwong): Find a way to share this path with
                    # ffmpeg.gyp so they don't diverge. (BUG=23602)
                    '<(PRODUCT_DIR)/libffmpegsumo.dylib',
                  ],
                },

The xcode generator doesn't define SHARED_LIB_DIR, so there's no xplat way to 
have a "copy shared_library somewhere" step.

Original comment by thakis@chromium.org on 18 Jul 2011 at 4:19

[GoogleCodeExporter]

I think I was thinking that shared_library isn't used anywhere anymore, but I 
admit I am fuzzy on how frameworks work in Mac Chrome.

Original comment by evan@chromium.org on 18 Jul 2011 at 5:09