Re: Exporting strlcat()?

From: Date: Wed, 16 May 2001 20:24:22 +0000
Subject: Re: Exporting strlcat()?
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-55586@lists.php.net to get a copy of this message
Daniel Stenberg wrote:
On Wed, 16 May 2001, Sterling Hughes wrote:
I get the following error when compiling PHP against cURL 7.7.3, any clues? /usr/local/lib/libcurl.a(strequal.o): In function `strlcat': /home/sterling/curl-7.7.3/lib/strequal.c:84: multiple definition of `strlcat'
I've attached the config.m4 (configuration file for cURL). Note, that on Linux systems (Mandrake 7.2, kernel 2.4.2 here), we define our own strlcat() and strlcpy() functions, which are slightly modified versions of the OpenBSD implementation. Also, nm reports that strlcat *is* exported by libcurl...
How does the PHP configure script figure out that it needs to define its own strlcat function?
From a quick grep of the source, it seems like the AC_REPLACE_FUNCS macro is used.
IMHO, PHP should first figure out what libs it needs and then it should look for missing functions to replace with its internal ones. That's how libcurl does, but when the configure script in curl runs, it doesn't find any strlcat() and thus uses its own version instead. Yes, I _could_ rename the strlcat() function to something else, but that would not be a really satisfactory solution for me, since the function is indeed used by people and it will be assumed to be around.
When did you add strlcat()? I only have this problem with 7.7.3. If its the internal code-base of cURL your worried about, the patch I sent you declaring it 'static inline' should make the function accessable within cURL itself. While, I see your point and I somewhat agree with you, I also think that curl shouldn't be exporting a function like strlcat() simply because the purpose of cURL is not that of a general purpose library, but rather a library for fetching URL's. If you'll notice strlcpy() is not exported (nm -g libcurl.so | grep strlcpy) from the library, as it is defined in krb4.c not a header file.
I figure you could run into problems with curl's own version of strlcpy() as well, from the very same reasons.
Well, not as it stands, but if you move it to krb4.h, then yes.
[ Feel free to forward this mail to whoever in the PHP project that might be interested or have an opinion in the matter. ]
I've CC'ed the php-dev mailing list on this. As I don't know PHP's build system as in depth as some of the people on this list do. -Sterling

« previous php.dev (#55586) next »