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 362708 - MinGW requires a -no-undefined flag as a linker parameter
MinGW requires a -no-undefined flag as a linker parameter
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-python
0.10.5
Other Windows
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-10-16 20:43 UTC by Marcus Granado
Modified: 2007-05-03 12:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Marcus Granado 2006-10-16 20:43:13 UTC 
I have been obtaining the following error when compiling gstreamer-0.10.10 using MingW and creating shared libraries (dlls):

libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries

This message shows when some library dependency is missing (e.g. -lpython24, -lws2_32 etc) and therefore not all symbols are being found when creating the DLL. In this case, the MinGW build defaults to a static library without reporting the error properly and stopping the build. Therefore, the user cannot promptly spot the problem when it occurs. 

This is a rather confusing error. In order to make MinGW report a more concise and helpful error (containing the symbols not found) and stop the build, it is necessary to include the flag -no-undefined as a link parameter. 

Adding this flag in the LDFLAGS variable (os in some equivalent linker variable) line of *ALL Makefiles* in *ALL gstreamer projects* (core, plugins, gst-python etc) that configure created for MinGW corrects the problem:

LDFLAGS = -no-undefined
Comment 1 Tim-Philipp Müller 2006-10-17 12:05:12 UTC 
I thought this had been fixed a while ago (there were a couple of related bugs/patches in bugzilla at least):

tim@sceptic:~$ grep -iHn no-undefined `find gst* -name configure.ac`
gst-plugins-bad/configure.ac:777:GST_ALL_LDFLAGS="-no-undefined"
gst-plugins-base/configure.ac:555:GST_ALL_LDFLAGS="-no-undefined"
gst-plugins-good/configure.ac:822:GST_ALL_LDFLAGS="-no-undefined"
gst-plugins-ugly/configure.ac:405:GST_ALL_LDFLAGS="-no-undefined"
gstreamer/configure.ac:455:GST_ALL_LDFLAGS="-no-undefined"

The Makefile.am of all our libs should contain $(GST_ALL_LDFLAGS).

Could you investigate why this isn't working for you? (or do you mean that this should be added for all plugins as well?)
Comment 2 Marcus Granado 2006-10-20 22:12:10 UTC 
oops, I verified this bug specifically when compiling gst-python-0.10.5, not gstreamer-core. sorry for the confusion. I'm trying to modify the component label and version of this bug. when I said 'all gstreamer-projects and plugins', I indeed was suggesting a double-check on all gstreamer modules for the presence of the flag -no-undefined, like in gst-python, gst-editor etc
Comment 3 Edward Hervey 2007-03-01 14:45:39 UTC 
Marcus, is this still an issue ? Is it specific to gst-python ?
Comment 4 Marcus Granado 2007-03-10 23:01:05 UTC 
(In reply to comment #3)
> Marcus, is this still an issue ? Is it specific to gst-python ?
> 
Hi, I really don't remember the details, since I'm not compiling gstreamer with mingw anymore :(
Comment 5 Tim-Philipp Müller 2007-05-03 12:43:51 UTC 
I think this has been fixed. Will close as OBSOLETE then. If it's still an issue, someone will run into it again sooner or later.