Issue 16621 - 11rc: tools patches for language and getopt
Summary: 11rc: tools patches for language and getopt
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 1.1 RC
Assignee: fa
QA Contact: issues@porting
URL:
Keywords:
Depends on:
Blocks: 16413
  Show dependency tree
 
Reported: 2003-07-09 16:57 UTC by fa
Modified: 2004-02-15 07:31 UTC (History)
3 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
cd to tools, patch -p0 < /path/to/patchfile (3.08 KB, patch)
2003-07-09 16:58 UTC, fa 		no flags Details | Diff
cd to tools, patch -p0 < /path/to/patchfile SUPERCEDES previous tools.xxx.11rc patches, moves some functions to library rather than headers (5.06 KB, patch)
2003-07-10 23:30 UTC, fa 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description fa 2003-07-09 16:57:06 UTC 
Bring in PORTS patch for system language, plus don't use custom getopt defines for gcc 3.3.
Comment 1 fa 2003-07-09 16:58:38 UTC 
Created attachment 7511 [details]
cd to tools, patch -p0 < /path/to/patchfile
Comment 2 khendricks 2003-07-10 15:33:12 UTC 
Hi,

Approved for commit to 1.1 once the tree reopens since completely MacOSX
specific.

Kevin
Comment 3 fa 2003-07-10 23:30:32 UTC 
Created attachment 7554 [details]
cd to tools, patch -p0 < /path/to/patchfile   SUPERCEDES previous tools.xxx.11rc patches, moves some functions to library rather than headers
Comment 4 fa 2003-07-10 23:34:18 UTC 
Explanation of the 071003 patch differences:

The problem was that when linking the vcl, or really any library that used the Time 
class, certain symbols created in the .eh frame on OS X would not be resolved.  At 
this point these two are the Time( const Time& ) constructor and the = operator 
functions.  The symptom was a link-time error complaining that these symbols 
should have been defined in Security.framework, which was not being linked in.  This 
is just the linker thinking its smart, but we don't want to link in Security.framework.

Therefore, the solution to make sure these symbols are resolved during link time is to 
make them available in the _tools_ library, not in the header.  So moving the 
implementations into the actual tools library code itself solves the problem, since the 
compiler will no longer generate the .eh frame code in the project that includes the 
<tools/time.hxx> file, but rather in the tools library where it can actually be found.

This may need to happen for other members of the Time class where conflicts with 
system frameworks appear.

Dan
Comment 5 khendricks 2003-07-11 01:24:29 UTC 
Hi Dan,

Should be fine.  Approved for 1.1

Kevin
Comment 6 fa 2003-07-14 15:23:00 UTC 
committed to cws_srx645_ooo11rc2
Comment 7 Martin Hollmichel 2004-02-15 07:27:50 UTC 
verfied in 1.1.0.
Comment 8 Martin Hollmichel 2004-02-15 07:31:01 UTC 
close issue