Ticket #138 (defect)
Opened 2 years ago
Last modified 1 year ago
build with omnithread fails on Windows
Status: closed (wontfix)
| Reported by: | dward | Assigned to: | jcorgan |
|---|---|---|---|
| Priority: | normal | Milestone: | to-be-decided |
| Component: | build | Version: | 3.1svn |
| Keywords: | cygwin, windows | Cc: | don2387ward@sprynet.com |
Build from svn under Cygwin fails because of problems with the new omnithread module:
(1) omnithread is built as a static library, not as a DLL; adding $(NO_UNDEFINED) to libgromnithread_la_LDFLAGS in omnithread/Makefile.am fixes this.
(2) The omnithread DLL is not searched when linking gnuradio_swig_py_runtime, gnuradio_swig_py_general, or gnuradio_swig_py_io; adding $(OMNITHREAD_LIBS) to _gnuradio_swig_py_{runtime,general,io}_la_LIBADD in gnuradio-core/src/lib/swig/Makefile.am fixes this.
(3) Similarly, $(OMNITHREAD_LIBS) is needed in gr-pager and gr-audio-portaudio (in *_la_LIBADD in src/Makefile.am).
(4) make check does not know where to find gromnithread.dll; this needs to be fixed in run_tests.sh.in. (OSX may need a similar fix.)
The attached patch file fixes the above problems on my Cygwin installation. I expect the same problems and fixes will apply to MSYS, but I have not tried that build yet with the new code. I don't know what impact these changes might have under Linux.
It appears that while Windows can import symbols from one DLL when building a second DLL, that second DLL does not contain enough information to build a third DLL that uses those symbols. Thus the answer to the "FIXME" question on line 60 of Makefile.common appears to be "no, it won't work on Windows". In fact, one way to fix (2) and (3) above would be to add the OMNITHREAD_LIBS flags to GNURADIO_CORE_LIBS in Makefile.common.
Attachments
Change History
02/11/07 17:42:20: Modified by dward
- attachment omni070211.patch added.
02/12/07 12:08:53: Modified by jcorgan
- status changed from new to assigned.
02/12/07 13:50:16: Modified by jcorgan
Trial fix in r4457 in developer branch jcorgan/ticket-138. Waiting for test results on Win32 platform; doesn't break anything on Linux.
02/12/07 16:06:31: Modified by jcorgan
Second trial fix at r4460 in branch jcorgan/ticket-138.
02/13/07 10:14:33: Modified by jcorgan
Fix @ 4471 in jcorgan/ticket-138 verified on Windows. Need to ensure it doesn't break elsewhere before merging to trunk.
02/15/07 11:37:45: Modified by jcorgan
- status changed from assigned to closed.
- resolution set to fixed.
- milestone changed from to-be-decided to release-3.1.
Fixed on trunk in r4484. Verified fixed on Win32, doesn't break Linux or OSX. Basic issue was that, for the first time, gnuradio-core has build dependency within the tree (the new omnithread library.) Makefile glue was updated to handle this.
02/28/07 15:28:35: Modified by dward
- status changed from closed to reopened.
- resolution deleted.
Since the change was backed out I am reopening the ticket.
The original patch used -L and -l to find omnithread. I think this is what allowed installed libraries to be found in some cases where uninstalled libraries were needed. A better solution would be to specify libgromnithread.la, e.g.:
OMNITHREAD_LA = $(top_builddir)/omnithread/libgromnithread.la
# How to link in GNU Radio core library from inside the tree
GNURADIO_CORE_LA = $(top_builddir)/gnuradio-core/src/lib/libgnuradio-core.la \
$(OMNITHREAD_LA)
(tested on Cygwin, but with unknown impact on other systems).
Ideally, libtool might be able to handle these interlibrary dependencies, but the current version appears to only add "-L" flags for one level of dependencies, which isn't nearly enough on Windows.
07/26/07 08:57:36: Modified by jcorgan
- milestone changed from release-3.1 to to-be-decided.
10/22/07 12:50:04: Modified by jcorgan
- version changed from 3.0svn to 3.1svn.
This has been fixed in the 3.1 stable release, but not on the trunk.
12/03/07 11:25:15: Modified by eb
- status changed from reopened to closed.
- resolution set to wontfix.
We won't fix this by breaking our code. The fix needs to go upstream in libtool for Cygwin. Please file a bug against libtool. We already provide the relevant information, there is no need to enter the interlibrary dependencies in more than one place. Doing so is a violation of the "write it once" principle.
fix build with new omnithread module on Windows