After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777528 - XCode Template does not work
XCode Template does not work
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: cerbero
1.11.1
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-01-20 10:32 UTC by Nick Kallen
Modified: 2018-11-03 10:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nick Kallen 2017-01-20 10:32:47 UTC
I'm using XCode 8 and the latest version of the framework .pkg.

Creating a new project from the template (I am using Swift) does not work.

When I compile, I first get errors missing these symbols:

  "_libiconv_set_relocation_prefix", referenced from:

Which I can fix by adding the linker flag -liconv to my Build Settings

However, when I enable #define GST_IOS_PLUGINS_EFFECTS, I get a ton of linking errors e.g., 

  "std::ostream& std::ostream::_M_insert<double>(double)", referenced from:
      webrtc::AgcManagerDirect::AnalyzePreProcess(short*, int, unsigned long) in GStreamer(libwebrtc_audio_processing_a_i386_-libwebrtc_audio_processing_la-agc_manager_direct.o)
  "std::__throw_length_error(char const*)", referenced from:
  "std::string::_Rep::_S_terminal", referenced from:

I assumed these were in stdc++ but that is already on the linker path.

FWIW, I have created a Objective-C/Swift bridge and module.map that allows me to use the library from Swift -- if anyone wants them.
Comment 1 Nick Kallen 2017-01-20 16:22:12 UTC
Even if you tell xcode to use the gnu stdc++ library rather than the new libc++, you must also force  xcode to use clang++ rather than clang to get past these errors. I did this, for example, by making a .mm file... There's got to be a better way.

However, the codecs plugin now fails with '"_opj_image_create", referenced from:' errors.
Comment 2 Nick Kallen 2017-01-20 16:37:30 UTC
I forgot to mention I also had to turn off 'Enable bitcode' in Build options otherwise I got 

ld: '/Users/nickkallen/Documents/Panel/Frameworks/GStreamer.framework/GStreamer(libglib-2_0_a_arm64_-libglib_2_0_la-gfileutils.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Comment 3 Sebastian Dröge (slomo) 2017-01-21 09:23:02 UTC
(In reply to Nick Kallen from comment #0)

> Which I can fix by adding the linker flag -liconv to my Build Settings

That's indeed needed and was forgotten to be added also to the template (the example applications all go it). Want to provide a patch?

> FWIW, I have created a Objective-C/Swift bridge and module.map that allows
> me to use the library from Swift -- if anyone wants them.

That would indeed be interesting. Did you base it on the GObject-Introspection information to also get information about how to do memory management?

(In reply to Nick Kallen from comment #1)
> Even if you tell xcode to use the gnu stdc++ library rather than the new
> libc++, you must also force  xcode to use clang++ rather than clang to get
> past these errors. I did this, for example, by making a .mm file... There's
> got to be a better way.

Yes you currently have to use the GNU C++ STL, see bug #766366. Which generally means that your "target" iOS version has to be set to 6.0 (or 7.0?) currently to make this work out of the box.

> However, the codecs plugin now fails with '"_opj_image_create", referenced
> from:' errors.

That's a bug in the 1.11.1 development release on platforms using static linking. Try 1.10.2 instead.

(In reply to Nick Kallen from comment #2)
> I forgot to mention I also had to turn off 'Enable bitcode' in Build options
> otherwise I got 

We don't built with bitcode, simply because it's not generally possible or easy to do. Quite a few libraries have assembly optimizations and are not plain C.
Comment 4 Nick Kallen 2017-01-30 16:10:31 UTC
(In reply to Sebastian Dröge (slomo) from comment #3)

> That's indeed needed and was forgotten to be added also to the template (the
> example applications all go it). Want to provide a patch?

I think over the next few weeks I will try to get up to speed with your codebase enough that I can make patches. I would like to make the changes specified in bug 771860, comment 6 , as well as some other changes to the generated framework so it can be used with Carthage. This requires me to get familiar with your cerbero recipes which have a steep learning curve. If I can succeed at this, it should make it much easier to install the framework and no longer require the template at all. I would appreciate any advice.

> > FWIW, I have created a Objective-C/Swift bridge and module.map that allows
> > me to use the library from Swift -- if anyone wants them.
> 
> That would indeed be interesting. Did you base it on the
> GObject-Introspection information to also get information about how to do
> memory management?

For now I've hand-coded it (it's just a hack/proof of concept). I'm sure I've made errors with the memory management as I'm neither an Objective C programmer nor a C programmer so I'm fumbling around a bit. Over the next few weeks I'd like to migrate to a code-gen approach using the GIR file, similar to how the C# bindings work. Here, for example, is the Objective-C header file:

https://gist.github.com/nkallen/6e3f5cf4e174a9d4f9d915fa9ca7a1a3#file-gst-h

And here is a swift translation of one of your ios demos (although I've changed the launch string):

https://gist.github.com/nkallen/6e3f5cf4e174a9d4f9d915fa9ca7a1a3#file-gstreamerservice-swift

The above actually works.

I'd like to make this a public package in some way. Do you have any advice Sebastian?
Comment 5 Nick Kallen 2017-01-30 16:24:37 UTC
Here is the objective-c implementation FWIW:

https://gist.github.com/nkallen/67f5d19d1198d86e7f6b4ee6a8e53571
Comment 6 Sebastian Dröge (slomo) 2017-01-31 11:12:54 UTC
(In reply to Nick Kallen from comment #4)
> (In reply to Sebastian Dröge (slomo) from comment #3)
> 
> > That's indeed needed and was forgotten to be added also to the template (the
> > example applications all go it). Want to provide a patch?
> 
> I think over the next few weeks I will try to get up to speed with your
> codebase enough that I can make patches. I would like to make the changes
> specified in bug 771860, comment 6 , as well as some other changes to the
> generated framework so it can be used with Carthage. This requires me to get
> familiar with your cerbero recipes which have a steep learning curve. If I
> can succeed at this, it should make it much easier to install the framework
> and no longer require the template at all. I would appreciate any advice.

What do you want to know? The best way to discuss this would probably be on the GStreamer IRC channel.


> I'd like to make this a public package in some way. Do you have any advice
> Sebastian?

For making it public? Just put it on GitHub for example :)
Comment 7 Olivier Crête 2018-05-05 14:34:47 UTC
Enabling bitcode embedding should be fixed by the patch from #770875 .. We also have to update the templates to match the changes I did to the gst example repo in the same bug.
Comment 8 Olivier Crête 2018-05-05 14:35:18 UTC
moving to the cerbero repo as we need to update the templates we ship in there to use libstdc++ and to enable bitcode!
Comment 9 GStreamer system administrator 2018-11-03 10:22:02 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/cerbero/issues/42.