| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #156
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | WIN32 |
|---|
| Summary: | Cannot staticly link with VC 7.1 |
|---|
| Version: | 1.1.4rc2 |
|---|
| Created By: | hupp.cs.wisc |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | hupp.cs.wisc
15:01 Sep 02, 2003 |
| We are trying to link against a static build of fltk 1.1.4rc4 built with visual studio 7.1. We are getting the following link error:
CameraWindow.obj : error LNK2019: unresolved external symbol "private:
__thiscall Fl_Widget::Fl_Widget(class Fl_Widget const &)"
(??0Fl_Widget@@AAE@ABV0@@Z) referenced in function "public: __thiscall
Fl_Group::Fl_Group(class Fl_Group const &)" (??0Fl_Group@@QAE@ABV0@@Z)
CameraWindow.obj : error LNK2019: unresolved external symbol "private:
class Fl_Widget & __thiscall Fl_Widget::operator=(class Fl_Widget const
&)" (??4Fl_Widget@@AAEAAV0@ABV0@@Z) referenced in function "public:
class Fl_Group & __thiscall Fl_Group::operator=(class Fl_Group const &)"
(??4Fl_Group@@QAEAAV0@ABV0@@Z)
A comment in Fl_Widget.H leads me to believe that this may be caused by different behavior in 7.1 compared to previous versions. This is the comment:
# if defined(WIN32) && !defined(FL_DLL)
// "de-implement" the copy constructors, EXCEPT for when we are using the WIN32 DLL
// interface, in which case we can't hide them because Microsoft requires the copy
// constructors to implement subclassing... | |
| |
| #2 | hupp.cs.wisc
11:28 Sep 03, 2003 |
| I mistakenly identified the version as 1.1.4rc4. It is actually rc2.
-Adam | |
| |
| #3 | mike
12:52 Sep 03, 2003 |
| Make sure you have all of the current service packs for VC++. This works on VC++ 6.0 and all versions of Borland and GCC compilers, so this sounds like a regression in the Microsoft tools.
You might also try removing the MS-specific stuff to see if that works, and if so let us know what VC++ 7.1-specific variables we can look for to make it compile out-of-the-box... | |
| |
| #4 | hupp.cs.wisc
15:30 Sep 03, 2003 |
| There are two possible solutions.
First, actually implementing the copy constructor and assignment operators fixes it. Since they should never get called this should be OK.
Fl_Widget & operator=(const Fl_Widget &) { return *this; }
Fl_Widget(const Fl_Widget &) {}
Second, the #ifdef can be changed to
# if defined(WIN32) && !defined(FL_DLL) && _MSC_VER < 1300
I don't know if 7.0 has the same problem, so the test may need to be tweaked.
It seems to me that the first solution is better since it maintains the protection of the functions.
-Adam | |
| |
| #5 | mike
12:06 Sep 04, 2003 |
| Adding the inline code seems to be the best approach and will have 0 overhead since it will never be called.
Commited to CVS for 1.1.4, thanks! | |
[ Return to Bugs & Features ]
|
| |
