rename functions as they conflict with glibc
I'm not sure if this problem is also fixed but this patch rename
functions as they conflict with glibc.
RR
diff -urN cdrkit-1.1.9/include/schily.h cdrkit-1.1.9_getline/include/schily.h
--- cdrkit-1.1.9/include/schily.h 2009-06-08 13:22:27.0 +0200
+++ cdrkit-1.1.9_getline/include/schily.h 2009-06-08 13:46:40.0
+0200
@@ -116,13 +116,13 @@
extern int fexecle(const char *, FILE *, FILE *, FILE *, const char *,
...);
/* 6th arg not const, fexecv forces av[ac] = NULL */
extern int fexecv(const char *, FILE *, FILE *, FILE *, int, char **);
-extern int fexecve(const char *, FILE *, FILE *, FILE *, char * const *,
+extern int cdr_fexecve(const char *, FILE *, FILE *, FILE *, char * const
*,
char * const *);
extern int fspawnv(FILE *, FILE *, FILE *, int, char * const *);
extern int fspawnl(FILE *, FILE *, FILE *, const char *, const char *,
...);
extern int fspawnv_nowait(FILE *, FILE *, FILE *, const char *, int,
char *const*);
-extern int fgetline(FILE *, char *, int);
+extern int cdr_fgetline(FILE *, char *, int);
extern int fgetstr(FILE *, char *, int);
extern voidfile_raise(FILE *, int);
extern int fileclose(FILE *);
@@ -190,7 +190,7 @@
extern char*fillbytes(void *, int, char);
extern char*findbytes(const void *, int, char);
extern int findline(const char *, char, const char *, int, char **, int);
-extern int getline(char *, int);
+extern int cdr_getline(char *, int);
extern int getstr(char *, int);
extern int breakline(char *, char, char **, int);
extern int getallargs(int *, char * const**, const char *, ...);
diff -urN cdrkit-1.1.9/librols/fexec.c cdrkit-1.1.9_getline/librols/fexec.c
--- cdrkit-1.1.9/librols/fexec.c2009-06-08 13:22:27.0 +0200
+++ cdrkit-1.1.9_getline/librols/fexec.c2009-06-08 13:46:33.0
+0200
@@ -170,7 +170,7 @@
} while (p != NULL);
va_end(args);
- ret = fexecve(name, in, out, err, av, env);
+ ret = cdr_fexecve(name, in, out, err, av, env);
if (av != xav)
free(av);
return (ret);
@@ -184,11 +184,11 @@
char *av[];
{
av[ac] = NULL; /* force list to be null terminated */
- return (fexecve(name, in, out, err, av, environ));
+ return (cdr_fexecve(name, in, out, err, av, environ));
}
EXPORT int
-fexecve(name, in, out, err, av, env)
+cdr_fexecve(name, in, out, err, av, env)
const char *name;
FILE *in, *out, *err;
char * const av[], * const env[];
diff -urN cdrkit-1.1.9/librols/getdomainname.c
cdrkit-1.1.9_getline/librols/getdomainname.c
--- cdrkit-1.1.9/librols/getdomainname.c2009-06-08 13:22:27.0
+0200
+++ cdrkit-1.1.9_getline/librols/getdomainname.c2009-06-08
13:32:40.0 +0200
@@ -83,7 +83,7 @@
if (f == NULL)
return (-1);
- while (fgetline(f, name1, sizeof (name1)) = 0) {
+ while (cdr_fgetline(f, name1, sizeof (name1)) = 0) {
if ((p = strchr(name1, '#')) != NULL)
*p = '\0';
diff -urN cdrkit-1.1.9/librols/stdio/fgetline.c
cdrkit-1.1.9_getline/librols/stdio/fgetline.c
--- cdrkit-1.1.9/librols/stdio/fgetline.c 2009-06-08 13:22:27.0
+0200
+++ cdrkit-1.1.9_getline/librols/stdio/fgetline.c 2009-06-08
13:32:19.0 +0200
@@ -37,7 +37,7 @@
*/
EXPORT int
-fgetline(f, buf, len)
+cdr_fgetline(f, buf, len)
registerFILE*f;
char*buf;
registerint len;
@@ -76,9 +76,9 @@
}
EXPORT int
-getline(buf, len)
+cdr_getline(buf, len)
char*buf;
int len;
{
- return (fgetline(stdin, buf, len));
+ return (cdr_fgetline(stdin, buf, len));
}
diff -urN cdrkit-1.1.9/libusal/scsitransp.c
cdrkit-1.1.9_getline/libusal/scsitransp.c
--- cdrkit-1.1.9/libusal/scsitransp.c 2009-06-08 13:22:27.0 +0200
+++ cdrkit-1.1.9_getline/libusal/scsitransp.c 2009-06-08 13:32:01.0
+0200
@@ -301,7 +301,7 @@
printf(%s, msg);
flush();
- if (getline(okbuf, sizeof (okbuf)) == EOF)
+ if (cdr_getline(okbuf, sizeof (okbuf)) == EOF)
exit(EX_BAD);
if (streql(okbuf, y) || streql(okbuf, yes) ||
streql(okbuf, Y) || streql(okbuf, YES))
diff -urN cdrkit-1.1.9/readom/io.c cdrkit-1.1.9_getline/readom/io.c
--- cdrkit-1.1.9/readom/io.c2009-06-08 13:22:27.0 +0200
+++ cdrkit-1.1.9_getline/readom/io.c2009-06-08 13:31:39.0 +0200
@@ -130,7 +130,7 @@
(*prt)(s, *lp, mini, maxi, dp);
flush();
line[0] = '\0';
- if (getline(line, 80) == EOF)
+ if (cdr_getline(line, 80) == EOF)
Re: rename functions as they conflict with glibc
Roman Rakus rra...@redhat.com wrote: I'm not sure if this problem is also fixed but this patch rename functions as they conflict with glibc. Your mail addresses two problems: The problem is that POSIX.1-2008 is in conflict with general rules in POSIX. POSIX as well as glibc illegally uses these names: POSIX grants that it will never break published older code. The POSIX standard for this reason was not allowed to use these names. The Standard Commitee has even been informed about the problem to no avail. Note that the names in question are in widely spread public use since 1982 with the interfaces used by libschily. So glibc is introducing a non-compliance because the functions using the same names in glibc implement different interfaces. Your problem is a result of using _extremely_ outdated and even illegal (*) sources from a questionable fork. *) illegal because in 2006, the initators of the fork introduced modifications that are in conflict with the Copyright law. The code you send cannot be legally distributed. I recommend you to just upgrade to recent original code. Original code is legally distributable and it does implement a workaround for the problem since the non-POSIX compliant ;-) POSIX.1-2008 has been approved in Summer 2008. Here is the recent original code: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Please upgrade all related code at RedHat's site as soon as possible and stop publishing the code you are currently distributing. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
Hi, this patch rename functions as they conflict with glibc. ... diff -urN cdrkit-1.1.9/libusal/scsitransp.c I am not sure whether cdrkit developers are around here. Probably you should post your patch to debburn-de...@lists.alioth.debian.org in order to make sure that it gets seen. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
Thomas Schmitt scdbac...@gmx.net wrote: this patch rename functions as they conflict with glibc. ... diff -urN cdrkit-1.1.9/libusal/scsitransp.c I am not sure whether cdrkit developers are around The development has been shut down on May 6th 2007. Also: Thomas please note that it does not make sense to talk about thisd software that cannot be legally distributed. Here is the official and legal software: cdrecord.berlios.de ftp://ftp.berlios.de/pub/cdrecord/alpha/ This software _is_ actively maintained. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
Hi, The development has been shut down on May 6th 2007. I had contact with Steve McIntyre after that date and except his admitted lack of time it did not seem as if cdrkit was declared discontinued. please note that it does not make sense to talk about thisd software that cannot be legally distributed. Well, Roman Rakus wanted to submit a patch and i pointed him to a place where it has more chance to get seen. If the question had been about alternatives then i would have promoted my own software, which is actively maintained, too. :)) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
Joerg Schilling wrote: Roman Rakus rra...@redhat.com wrote: I'm not sure if this problem is also fixed but this patch rename functions as they conflict with glibc. Your mail addresses two problems: The problem is that POSIX.1-2008 is in conflict with general rules in POSIX. POSIX as well as glibc illegally uses these names: POSIX grants that it will never break published older code. The POSIX standard for this reason was not allowed to use these names. The Standard Commitee has even been informed about the problem to no avail. Note that the names in question are in widely spread public use since 1982 with the interfaces used by libschily. So glibc is introducing a non-compliance because the functions using the same names in glibc implement different interfaces. I'm sad that you are still beating this dead horse. You waste your time and energy debating an issue long since settled. It no longer matters if you are right, neither POSIX nor the millions of applications using POSIX definitions are going to change. You are taking the policy on breaking existing programs using older POSIX compliant libraries, and trying to convince them that it applies to applications written against other libraries using the same names. Einstein is credited with saying that the definition of stupidity (some claim he said futility) is doing the same thing over and over hoping for a different result. Your problem is a result of using _extremely_ outdated and even illegal (*) sources from a questionable fork. *) illegal because in 2006, the initators of the fork introduced modifications that are in conflict with the Copyright law. The code you send cannot be legally distributed. You should get a lawyer or get a life. Why do you fritter away your time revisiting this issue? I recommend you to just upgrade to recent original code. Original code is legally distributable and it does implement a workaround for the problem since the non-POSIX compliant ;-) POSIX.1-2008 has been approved in Summer 2008. Here is the recent original code: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Please upgrade all related code at RedHat's site as soon as possible and stop publishing the code you are currently distributing. Redhat and other gave up your version because you were too difficult to work with. Since your willingness to accept other views as having merit hasn't changed, neither will the decision to use a hack on you old code. The problem is of your making. -- Bill Davidsen david...@tmr.com Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a normal user and is setuid root, with the vi line edit mode selected, and the character set is big5, an off-by-one error occurs during wildcard (glob) expansion. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
Bill Davidsen david...@tmr.com wrote: Here is the recent original code: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Please upgrade all related code at RedHat's site as soon as possible and stop publishing the code you are currently distributing. Redhat and other gave up your version because you were too difficult to work with. Since your willingness to accept other views as having merit hasn't changed, neither will the decision to use a hack on you old code. The problem is of your making. No, Redhat is a victim of a non-cooperative downstream that started a slander campaign against me and my software. The people wo are not part of the slander campaign know that I am a very cooperative person and that reported bugs are typpically fixed in less time than e.g. the Debian bug tracking system needs to accept the report. As a result, there ar no known bugs in the original software. On the other side, there are currently approx. 150 unique bugs if you sum up all entries from all bug tracking systems for the fork. These bugs are waiting since more than two years for being fixed Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
On Mo, 15 Jun 2009, Joerg Schilling wrote: I recommend you to just upgrade to recent original code. Original code is legally distributable and it does implement a workaround for the problem since What do Sun's lawyers say to that, and to your cdrecord mixture, about non-distributability? Stop FUD. Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- BUDE A polite joke reserved for use in the presence of vicars. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
Thomas Schmitt scdbac...@gmx.net wrote: The development has been shut down on May 6th 2007. I had contact with Steve McIntyre after that date and except his admitted lack of time it did not seem as if cdrkit was declared discontinued. A bit of reality check helps a lot The original software has a sustained SCCS putback rate of 2.5..3 modifications per day. The fork did have 63 modifications since May 6th 2007. This is why more than 100 bugs are not fixed and why the fork does not offer the features one typically expects from such software today. Using the fork means riding a dead horse. please note that it does not make sense to talk about thisd software that cannot be legally distributed. Well, Roman Rakus wanted to submit a patch and i pointed him to a place where it has more chance to get seen. The problem is that the fork is in conflict with the copyright law and thus cannot be legally distributed. The original software does not need the patch, so why bother? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: rename functions as they conflict with glibc
Norbert Preining prein...@logic.at wrote: On Mo, 15 Jun 2009, Joerg Schilling wrote: I recommend you to just upgrade to recent original code. Original code is legally distributable and it does implement a workaround for the problem since What do Sun's lawyers say to that, and to your cdrecord mixture, about non-distributability? We all know that you are sending repeated FUD to this list According to my request, Sun's lawyers did have another full legal review last year and confirmed that the original software is of course without legal problems. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
