Issue 17841 - unzip exporting crazy global symbols ...
Summary: unzip exporting crazy global symbols ...
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC2
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 1.1.1
Assignee: Olaf Felka
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-04 10:06 UTC by mmeeks
Modified: 2004-01-28 09:46 UTC (History)
2 users (show)

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

Attachments
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 mmeeks 2003-08-04 10:06:16 UTC 
This small patch makes me sleep better at night, since it stops libzipNNN.so
exporting global symbols like 'statbuf', 'aflags', 'match', 'area', 'hold' and
other equally silly things.

May I commit ?

--- /dev/null   2003-01-30 10:24:37.000000000 +0000
+++ unzip/util/svunzip.map      2003-08-04 10:06:01.000000000 +0100
@@ -0,0 +1,9 @@
+SVUNZIP_1_0 {
+       global:
+               getCRC32;
+               SVUnzip;
+               SVUnzipEnumFiles;
+               GetVersionInfo;
+       local:
+               *;
+};
Index: unzip/util/makefile.mk
===================================================================
RCS file: /cvs/util/unzip/util/makefile.mk,v
retrieving revision 1.3
diff -u -p -u -r1.3 makefile.mk
--- unzip/util/makefile.mk      13 Aug 2002 12:58:26 -0000      1.3
+++ unzip/util/makefile.mk      4 Aug 2003 09:01:35 -0000
@@ -88,6 +88,7 @@ LIB1FILES=  \
 SHL1TARGET=zip$(UPD)$(DLLPOSTFIX)
 SHL1IMPLIB= i$(TARGET)
 SHL1LIBS=$(LIB2TARGET)
+SHL1VERSIONMAP= $(TARGET).map
 SHL1DEF=    $(MISC)$/$(SHL1TARGET).def
 .ENDIF
Comment 1 Martin Hollmichel 2003-08-15 10:36:05 UTC 
mh->dv: should we consider this for 1.1.1 ?
Comment 2 matthias.huetsch 2003-08-15 10:56:16 UTC 
Hi all,

Without doubt, Michael's patch is the right thing to do.

The only thing that needs verification, is the completeness of the
exported symbols. As I don't know of any reverse dependencies of
'libzip...so' (other shared libraries linking against libzip$(UPD)...),
I assume that it is only dynamically loaded.

Thus, we would need to find (or make) some *definition* of what the
API of libzip$(UPD)... really is. Not just an 'arbitrary' mapfile.

But otherwise, yes please go ahead as proposed.

Matthias
Comment 3 matthias.huetsch 2003-08-15 11:45:15 UTC 
Hi Dirk, Michael,

a quick look into 'unzip/prj/d.lst' (delivering one header file, only,
i.e. 'svunzip.h') and into 'unzip/inc/svunzip.h' shows, that Michael's
mapfile exactly fits.

Thus, libzip$(UPD)...so implements an API consisting of three symbols,
namely 'getCRC32', 'SVUnzip' and 'SVUnzipEnumFiles'.

So the patch is correct and approved.

Matthias
Comment 4 dirk.voelzke 2003-08-18 08:34:18 UTC 
.
Comment 5 dirk.voelzke 2003-10-27 12:58:29 UTC 
Fixed in cws SetupPP01.
Comment 6 dirk.voelzke 2003-10-27 14:47:58 UTC 
Please verify.
Comment 7 Olaf Felka 2003-10-28 15:40:45 UTC 
Looks good for me.
Comment 8 Olaf Felka 2003-10-28 15:41:21 UTC 
Verified in cws setuppp01.
Comment 9 Olaf Felka 2004-01-28 09:46:24 UTC 
.