building Lighttpd 1.4.30 using gcc 4.4.6: ___builtin_stdarg_start referenced

[Lewis Rosenthal]

Greetings, all...

It would surely be more fun building things if I could actually get
something to work every now and again. ;-) If I couldn't do this on
Linux with some success, I would probably chalk it up to my own lack of
ability. Anyway...

Trying to build the above, running make, I get:

lemon.c: In function 'ErrorMsg':
lemon.c:1305: warning: implicit declaration of function
'__builtin_stdarg_start'

lemon.c:1305: warning: 'ap' is used uninitialized in this function
mv -f .deps/lemon.Tpo .deps/lemon.Po
ash.exe ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -W -Wshadow
-pedant
ic -std=gnu99 -o lemon.exe lemon.o
libtool: link: gcc -g -O2 -Wall -W -Wshadow -pedantic -std=gnu99 -o
lemon.exe le
mon.o
lemon.c:1305 (lemon.o): Undefined symbol ___builtin_stdarg_start
referenced from
text segment
gcc: Internal error: Hangup (program ld.exe)

My reading of some gcc info tells me that ___builtin_stdarg_start was
deprecated by 2008 or so (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35460), and in fact, line
1305 of lemon.c references va_start:

va_start(ap, format);
/* Prepare a prefix to be prepended to every output line */
if( lineno>0 ){
sprintf(prefix,"%.*s:%d: ",PREFIXLIMIT-10,filename,lineno);
}else{
sprintf(prefix,"%.*s: ",PREFIXLIMIT-10,filename);
}
prefixsize = strlen(prefix);
availablewidth = LINEWIDTH - prefixsize;

/* Generate the error message */
vsprintf(errmsg,format,ap);
va_end(ap);
errmsgsize = strlen(errmsg);
/* Remove trailing '\n's from the error message. */
while( errmsgsize>0 && errmsg[errmsgsize-1]=='\n' ){
errmsg[--errmsgsize] = 0;
}

I've tried this both with Paul's packaged gcc446 (and the included
gcc446.cmd, edited to reference j: instead of u:, to fit my setup), and
with the 4.4.6 build installed via yum (which was no mean feat, as
"/usr/lib/libiberty.a from install of gcc-4.4.6-11.oc00.i386 conflicts
with file from package binutils-static-2.21-1.oc00.i386" - I finally
forced it).

Anyway, I get the same stall using either gcc 4.4.6. Is
___builtin_stdarg_start defined (incorrectly) somewhere?

TIA

--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC www.2rosenthals.com
Need a managed Wi-Fi hotspot? www.hautspot.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

[Dave Yeo]

You're including the wrong stdarg.h. You need the one that comes with
gcc 4.4.6 which will use __builtin_va_start(). Perhaps back up the one
in usr\include and replace with the one in local446\include\386
You also need to file a bug(s) against YUM, both for stdarg and libiberty.
Dave

[Lewis Rosenthal]

On 12/26/11 12:30 am, Dave Yeo thus wrote :

> Lewis Rosenthal wrote:
>> Greetings, all...
>>
>> It would surely be more fun building things if I could actually get
>> something to work every now and again. ;-) If I couldn't do this on
>> Linux with some success, I would probably chalk it up to my own lack of
>> ability. Anyway...
>>
>> Trying to build the above, running make, I get:
>>
>> lemon.c: In function 'ErrorMsg':
>> lemon.c:1305: warning: implicit declaration of function
>> '__builtin_stdarg_start'
>>

<snip>

>> My reading of some gcc info tells me that ___builtin_stdarg_start was
>> deprecated by 2008 or so (see
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35460), and in fact, line
>> 1305 of lemon.c references va_start:
>>
>> va_start(ap, format);

<snip>

>> I've tried this both with Paul's packaged gcc446 (and the included
>> gcc446.cmd, edited to reference j: instead of u:, to fit my setup), and
>> with the 4.4.6 build installed via yum (which was no mean feat, as
>> "/usr/lib/libiberty.a from install of gcc-4.4.6-11.oc00.i386 conflicts
>> with file from package binutils-static-2.21-1.oc00.i386" - I finally
>> forced it).
>>
>> Anyway, I get the same stall using either gcc 4.4.6. Is
>> ___builtin_stdarg_start defined (incorrectly) somewhere?
>>
>> TIA
>>
> You're including the wrong stdarg.h. You need the one that comes with
> gcc 4.4.6 which will use __builtin_va_start(). Perhaps back up the one
> in usr\include and replace with the one in local446\include\386
> You also need to file a bug(s) against YUM, both for stdarg and libiberty.
>

Ah, thanks, Dave. This makes sense. I should have looked for the
obvious, I guess!

I'll see to opening those bugs, too.

Cheers/2

[Lewis Rosenthal]

On 12/26/11 04:37 pm, Lewis Rosenthal thus wrote :

Okay, a bit further...

I had several stdarg.h's in the path:

Directory of J:\usr\include\stdarg.h

10-03-11 0:07 44 124 stdarg.h

which was a hardlink to:

Directory of J:\usr\include\386\stdarg.h

3-18-06 7:19 3,387 0 stdarg.h

and another hardlink from that over here:

Directory of J:\usr\include\machine\stdarg.h

10-03-11 0:07 40 124 stdarg.h

rpm's final go at installing 446 added (I believe):

Directory of J:\usr\include\c++\4.4.6\tr1\stdarg.h

12-13-11 12:51 1,215 124 stdarg.h

So, while I could change the hardlinks easily enough, I was still
running into trouble, as J:\usr\include\c++\4.4.6\tr1\stdarg.h was
pointing to relative paths under tr1/. To work around this, I changed
C_INCLUDE_PATH to match CPLUS_INCLUDE_PATH, which pushed
J:/USR/local/include/c++/4.4.6 ahead of J:/USR/include. This resolved
the issue with __builtin_stdarg_start, and got me all the way down to
some other mess:

libtool: link: gcc -Zdll -Zcrtdll -o .libs/mod_flv_streaming.dll
.libs/mod_flv_streaming.o -O2 .libs/mod_flv_streaming.def
mod_flv_streaming.c:267 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_init_string referenced from text segment
mod_flv_streaming.c:59 (.libs/mod_flv_streaming.o): Undefined symbol
_array_free referenced from text segment
mod_flv_streaming.c:66 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_free referenced from text segment
mod_flv_streaming.c:67 (.libs/mod_flv_streaming.o): Undefined symbol
_array_free referenced from text segment
mod_flv_streaming.c:93 (.libs/mod_flv_streaming.o): Undefined symbol
_array_init referenced from text segment
mod_flv_streaming.c:99 (.libs/mod_flv_streaming.o): Undefined symbol
_config_insert_values_global referenced from text segment
mod_flv_streaming.c:194 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_is_empty referenced from text segment
mod_flv_streaming.c:121 (.libs/mod_flv_streaming.o): Undefined symbol
_config_check_cond referenced from text segment
mod_flv_streaming.c:127 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_is_equal_string referenced from text segment
mod_flv_streaming.c:216 (.libs/mod_flv_streaming.o): Undefined symbol
_array_reset referenced from text segment
mod_flv_streaming.c:217 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_copy_string_buffer referenced from text segment
mod_flv_streaming.c:220 (.libs/mod_flv_streaming.o): Undefined symbol
_array_get_element referenced from text segment
mod_flv_streaming.c:236 (.libs/mod_flv_streaming.o): Undefined symbol
_stat_cache_get_entry referenced from text segment
mod_flv_streaming.c:245 (.libs/mod_flv_streaming.o): Undefined symbol
_chunkqueue_get_append_buffer referenced from text segment
mod_flv_streaming.c:246 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_copy_string_len referenced from text segment
mod_flv_streaming.c:248 (.libs/mod_flv_streaming.o): Undefined symbol
_http_chunk_append_file referenced from text segment
mod_flv_streaming.c:250 (.libs/mod_flv_streaming.o): Undefined symbol
_response_header_overwrite referenced from text segment
mod_flv_streaming.c:166 (.libs/mod_flv_streaming.o): Undefined symbol
_array_get_unused_element referenced from text segment
mod_flv_streaming.c:169 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_copy_string_len referenced from text segment
mod_flv_streaming.c:170 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_copy_string_len referenced from text segment
mod_flv_streaming.c:172 (.libs/mod_flv_streaming.o): Undefined symbol
_array_insert_unique referenced from text segment
mod_flv_streaming.c:167 (.libs/mod_flv_streaming.o): Undefined symbol
_data_string_init referenced from text segment
mod_flv_streaming.c:37 (.libs/mod_flv_streaming.o): Undefined symbol
_buffer_init referenced from text segment
mod_flv_streaming.c:38 (.libs/mod_flv_streaming.o): Undefined symbol
_array_init referenced from text segment

gcc: Internal error: Hangup (program ld.exe)

Hmmm... I can only suspect that it has something to do with:

#include <ctype.h>
#include <stdlib.h>
#include <string.h>

and the versions I'm getting loaded (the above is from
mod_flv_streaming.c in the /src directory for Lighttpd). I'll have to
keep picking away at it until I figure out what's messed up in the
include path causing the breakage.

If I completely remove (rather, rename) /usr/include, I wonder what
might break? Also, now that I have *both* Paul's zipped 446 package
*and* the yum-supplied rpm installed, I've likely created a mess for
myself, if only confusing the jungle of paths to follow.

Anyway, Dave, if you have any other thoughts on the subject, I'm all
ears. I don't want this to take you away from more important stuff, though.

Thanks again for the pointer about watching the includes. ;-)

[Dave Yeo]

For reference I have,
C_INCLUDE_PATH=I:/usr/local446/lib/gcc/i386-pc-os2-emx/4.4.6/include;I:/usr/local446/include;I:/usr/include
CPLUS_INCLUDE_PATH=I:/usr/local446/include/c++/4.4.6;I:/usr/local446/include/c++/4.4.6/i386-pc-os2-emx;I:/usr/local446/include/c++/4.4.6/backward;I:/usr/local446/include;I:/usr/include
LIBRARY_PATH=I:/usr/local446/lib/gcc/i386-pc-os2-emx/4.4.6;I:/usr/local446/lib;I:/usr/lib

>
> libtool: link: gcc -Zdll -Zcrtdll -o .libs/mod_flv_streaming.dll

After running configure, I'd search libtool and add a -Zomf besides each
occurrence of -Zdll, should be 2 or 3.
A lot of libtools also have a bug where after creating the OS/2 DLL and
import library it'll then symlink the DLL against the DEF and the import
library against the original DLL. Unluckily I can't remember the fix
offhand besides the obvious one of running libtoolize with an OS/2
version of libtool.
Best at first to run configure --disable-shared --enable-static to get
it running. Don't forget to run configure --help to see if there are
other things that you should disable or enable.

> .libs/mod_flv_streaming.o -O2 .libs/mod_flv_streaming.def
> mod_flv_streaming.c:267 (.libs/mod_flv_streaming.o): Undefined symbol
> _buffer_init_string referenced from text segment

[bunch of similar errors]

> gcc: Internal error: Hangup (program ld.exe)

I have none of these symbols anywhere. I'd guess that they are part of
lighttpd. Try searching your source tree for the missing symbols without
the leading underscore prefix. The build is probably not linking in a
static lib or linking in the wrong order. (On OS/2 (and Windows) the
linking order can be important, if foo.a depends on bar.a IIRC -lbar
must come before -lfoo or maybe the other way around. There are even
times when you need -lfoo -lbar -lfoo -lbar if they have lots of
inter-dependencies.

>
> Hmmm... I can only suspect that it has something to do with:
>
> #include <ctype.h>
> #include <stdlib.h>
> #include <string.h>
>
> and the versions I'm getting loaded (the above is from
> mod_flv_streaming.c in the /src directory for Lighttpd). I'll have to
> keep picking away at it until I figure out what's messed up in the
> include path causing the breakage.
>
> If I completely remove (rather, rename) /usr/include, I wonder what
> might break?

Everything :)

> Also, now that I have *both* Paul's zipped 446 package
> *and* the yum-supplied rpm installed, I've likely created a mess for
> myself, if only confusing the jungle of paths to follow.

Yes, you should have installed them to different partitions.
I have different scripts to enable different build environments with
only the minimal in config.sys

>
> Anyway, Dave, if you have any other thoughts on the subject, I'm all
> ears. I don't want this to take you away from more important stuff, though.
>
> Thanks again for the pointer about watching the includes. ;-)

Perhaps I'll try building lighttpd just to see if it is simple
Dave

[Dave Yeo]

Dave Yeo wrote:
> Perhaps I'll try building lighttpd just to see if it is simple

I had to disable pcre in configure as I was too lazy to install it.
The build depended on mmap, so I used Yuri's port, swapped headers and
built with make LDFLAGS=-lmmap.
The build died from needing getaddrinfo() which our libc is missing.
Perhaps Pauls build environment has it added?
Anyways if you want to do the work, there is a version in the rsync
sources that could be ripped out, otherwise it'll need modifying to use
gethostbyname().\
The build system seems really stupid too as it seems to make a static
lib for every object file. Lots of potential for linking in the wrong order.
Definitely not a simple port.
Dave

[Lewis Rosenthal]

On 12/27/11 03:09 am, Dave Yeo thus wrote :

Wow...

Thanks so much for the wealth of information, Dave. Perhaps it doesn't
seem so complex to you, but on my side of the equation, you've really
turned a light on for stuff I've never taken the time to wrap my head
around (and of course, one of the dangers of doing this under Linux
regularly, and not on other platforms, is that when things "just work,"
one tends to disregard the "why" and the "how").

I noticed during configure that gethostbyname initially barfed, then
later seemed to indicate that it was okay (of course, this was during
configure, and not while linking). I hadn't gotten that far into the
process to see it actually fail. I was encouraged with the config option
--disable-ipv6, as I ran across that some time ago with another project,
and had to stub around all of the ipv6 stuff manually, which was a chore.

I'm also encouraged from a cpability standpoint by your comment that
this is definitely not a simple port. At least I don't feel like such a
dunce (for the moment). ;-)

I'll give this another look over the weekend, and perhaps clean up the
two gcc installations I currently have, if only to head off potential
conflicts.

Thanks again for all of your time and excellent insight. Cheers, and
Happy 2012.