0000728: [PORTABILITY] GNU libc asprintf dependency

Notes
(0001122) vodz 02-20-06 03:19	Its require the auto configure infrastructure. I don`t know, how detect supporting asprintf in libbb internally in the compiling process.

(0001145) rfelker 02-28-06 00:27	I've found other dependencies on GNU functions too, like strndup (that one is stupid though since it obviously should be replaced by bb_xstrdup). IMO one possible solution is to have a manual configuration option to disable dependence on all GNU-specific functions and use portable replacements for them (at a possible but minor size/performance penalty).

(0001149) rfelker 02-28-06 14:17	I just uploaded a patch with fixes for this and several other GNU-isms. The others can all easily be fixed without any option since BusyBox already has its own function in libbb to match. However, the patch has vasprintf inside #ifdef HAVE_GNU_EXTENSIONS which is obviously not going to make everyone happy unless HAVE_GNU_EXTENSIONS is selectable somewhere. On the other hand, maybe it's desirable to always use my version since vasprintf may not have the desired malloc error checking..? Other portability issues remain, especially the inclusion of Linux-specific modules in libbb even if the applets which use them are disabled. I'll attempt to submit more patches later.

(0001150) vodz 02-28-06 21:34	My (very old) local copy ucLibc 0.9.20 have not HAVE_GNU_EXTENSIONS.

(0001152) rfelker 03-01-06 06:03	Of course it doesn't. As I said in my note, this is an undefined macro which would have to be added somewhere in busybox configuration if you want to use vasprintf. Whether there's any good reason to want to use it is open to question. Anyway this is just one part of the patch. The other fixes should all be clean and noncontroversial.

(0001181) landley 03-09-06 14:22	svn 14498. I'd suggest setting the #define in platform.h.

(0001182) rfelker 03-09-06 15:01	Some of the changes were reverted in 14499, recreating the issue with netinet/in.h. A much cleaner solution would be to always include both.

(0001183) landley 03-09-06 15:15	Then post about it on the list, please. The bug generator isn't the appropriate place for this kind of discussion. The patch attached to this issue was applied. If there's an issue, it's a new issue. I did 14499 because your change introduced warnings to linux. You'll notice that platform.h (which is included from both libbb.h and inet_common.h) now includes netinet/in.h for apple and arpa/inet.h for everything else. How is this a regression? What did it break? If it reverted anything, it was unintentional. Apple should be getting the right header, and Linux should be getting the right header. They should be getting them from platform.h, which is the right place to make decisions like that.

Issue History
Date Modified	Username	Field	Change
02-18-06 10:18	rfelker	New Issue
02-18-06 10:18	rfelker	Status	new => assigned
02-18-06 10:18	rfelker	Assigned To	=> BusyBox
02-20-06 03:19	vodz	Note Added: 0001122
02-20-06 03:19	vodz	Status	assigned => acknowledged
02-20-06 03:19	vodz	Resolution	open => suspended
02-28-06 00:27	rfelker	Note Added: 0001145
02-28-06 13:54	rfelker	File Added: portability1.diff
02-28-06 14:17	rfelker	Note Added: 0001149
02-28-06 21:34	vodz	Note Added: 0001150
03-01-06 06:03	rfelker	Note Added: 0001152
03-09-06 14:22	landley	Status	acknowledged => closed
03-09-06 14:22	landley	Note Added: 0001181
03-09-06 15:01	rfelker	Status	closed => feedback
03-09-06 15:01	rfelker	Resolution	suspended => reopened
03-09-06 15:01	rfelker	Note Added: 0001182
03-09-06 15:15	landley	Status	feedback => closed
03-09-06 15:15	landley	Note Added: 0001183
03-09-06 15:15	landley	Resolution	reopened => fixed

Relationships