On Tue, 2005-09-20 at 10:02 -1000, Warren Togami wrote:
> Jeremy Katz wrote:
> > On Tue, 2005-09-20 at 19:11 +0200, Miloslav Trmac wrote:
> >
> >>Providing a real library (which can be empty and just require
> >>libgif.so.4) also solves the provides: (64bit) problems.
> >
> >
> > This feels a bit cleaner to me and thus would get my vote
> >
>
> How about we keep the versioned libungif symlink for runtime compat, but
> remove libungif.so and libungif-devel provides so packages must build
> against giflib-devel explicitly?
>
> This would still require the if conditional for the libungif Provides,
> but otherwise is correct.
Well -- here's a spec that implements the procedure Miloslav suggested.
It seems reasonable from the packaging side::
MAJOR=`echo '%{version}' | sed 's/\([0-9]\+\)\..*/\1/'`
%{__cc} $RPM_OPT_FLAGS -shared -Wl,-soname -Wl,libungif.so.$MAJOR \
-Llib/.libs -lgif -o libungif.so.%{version}
Plus three lines to install and symlink the library.
Warren's 64bit Provides conditional is pretty snazzy as well:
%if %{_lib} == lib64
Provides: libungif.so.4()(64bit)
%else
Provides: libungif.so.4
%endif
Which one is better depends on whether we want to actively discourage
libungif linking. Seeing as there are probably upstream authors who may
run FC5 and want to make their own rpms for distribution, allowing
-lungif to create a binary with potential to run on <FC5 may be a plus.
spec & patch for an x86_64 blocker attached.
RPMS available here:
http://www.tiki-lounge.com/~toshio/fedora/
-Toshio
Attachment:
giflib.spec
Description: application/extension-spec
--- giflib-4.1.3/lib/gif_hash.c.64 2005-09-20 13:39:32.000000000 -0700
+++ giflib-4.1.3/lib/gif_hash.c 2005-09-20 13:41:40.000000000 -0700
@@ -45,7 +45,7 @@
NumberOfMisses = 0;
#endif /* DEBUG_HIT_RATE */
-static int KeyItem(unsigned long Item);
+static int KeyItem(unsigned int Item);
/******************************************************************************
* Initialize HashTable - allocate the memory needed and clear it. *
@@ -69,17 +69,17 @@
******************************************************************************/
void _ClearHashTable(GifHashTableType *HashTable)
{
- memset(HashTable -> HTable, 0xFF, HT_SIZE * sizeof(long));
+ memset(HashTable -> HTable, 0xFF, HT_SIZE * sizeof(int));
}
/******************************************************************************
* Routine to insert a new Item into the HashTable. The data is assumed to be *
* new one. *
******************************************************************************/
-void _InsertHashTable(GifHashTableType *HashTable, unsigned long Key, int Code)
+void _InsertHashTable(GifHashTableType *HashTable, unsigned int Key, int Code)
{
int HKey = KeyItem(Key);
- unsigned long *HTable = HashTable -> HTable;
+ unsigned int *HTable = HashTable -> HTable;
#ifdef DEBUG_HIT_RATE
NumberOfTests++;
@@ -99,10 +99,10 @@
* Routine to test if given Key exists in HashTable and if so returns its code *
* Returns the Code if key was found, -1 if not. *
******************************************************************************/
-int _ExistsHashTable(GifHashTableType *HashTable, unsigned long Key)
+int _ExistsHashTable(GifHashTableType *HashTable, unsigned int Key)
{
int HKey = KeyItem(Key);
- unsigned long *HTable = HashTable -> HTable, HTKey;
+ unsigned int *HTable = HashTable -> HTable, HTKey;
#ifdef DEBUG_HIT_RATE
NumberOfTests++;
@@ -127,7 +127,7 @@
* Because the average hit ratio is only 2 (2 hash references per entry), *
* evaluating more complex keys (such as twin prime keys) does not worth it! *
******************************************************************************/
-static int KeyItem(unsigned long Item)
+static int KeyItem(unsigned int Item)
{
return ((Item >> 12) ^ Item) & HT_KEY_MASK;
}
--- giflib-4.1.3/lib/gif_hash.h.64 2005-09-20 13:39:42.000000000 -0700
+++ giflib-4.1.3/lib/gif_hash.h 2005-09-20 13:42:08.000000000 -0700
@@ -25,12 +25,12 @@
#define HT_PUT_CODE(l) (l & 0x0FFF)
typedef struct GifHashTableType {
- unsigned long HTable[HT_SIZE];
+ unsigned int HTable[HT_SIZE];
} GifHashTableType;
GifHashTableType *_InitHashTable(void);
void _ClearHashTable(GifHashTableType *HashTable);
-void _InsertHashTable(GifHashTableType *HashTable, unsigned long Key, int Code);
-int _ExistsHashTable(GifHashTableType *HashTable, unsigned long Key);
+void _InsertHashTable(GifHashTableType *HashTable, unsigned int Key, int Code);
+int _ExistsHashTable(GifHashTableType *HashTable, unsigned int Key);
#endif /* _GIF_HASH_H_ */
--- giflib-4.1.3/lib/egif_lib.c.64 2005-09-20 13:45:28.000000000 -0700
+++ giflib-4.1.3/lib/egif_lib.c 2005-09-20 13:43:39.000000000 -0700
@@ -188,6 +188,12 @@
_GifError = E_GIF_ERR_NOT_ENOUGH_MEM;
return NULL;
}
+ if ((Private->HashTable = _InitHashTable()) == NULL) {
+ free(GifFile);
+ free(Private);
+ _GifError = E_GIF_ERR_NOT_ENOUGH_MEM;
+ return NULL;
+ }
GifFile->Private = (VoidPtr) Private;
Private->FileHandle = 0;
@@ -832,7 +838,7 @@
/* Form a new unique key to search hash table for the code combines
* CrntCode as Prefix string with Pixel as postfix char.
*/
- NewKey = (((unsigned long) CrntCode) << 8) + Pixel;
+ NewKey = (((unsigned int) CrntCode) << 8) + Pixel;
if ((NewCode = _ExistsHashTable(HashTable, NewKey)) >= 0) {
/* This Key is already there, or the string is old one, so
* simple take new code as our CrntCode:
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
