Re: glib2-2.20.4-1

On Mon, Jul 06, 2009 at 10:19:07PM +0200, Peter Dyballa wrote:
> Hello!
> 
> There are some unclarities with this package:
> 
> 	checking for the BeOS... no
> 	checking for Win32... no
> 	checking for Mac OS X Carbon support... checking for style of  
> include used by make... GNU
> 	checking for gcc... gcc
> 	checking for C compiler default output file name... a.out
> 
> Why has it to be "Carbon?"

Why would you not want carbon if it's available? It maybe doesn't
*have to* use it (that's why there's a ./configure test for its
availability), but it presumably adds some feature or takes advantage
of improved implemenation if found.

> 	checking dependency style of gcc... none
> 	checking how to run the C preprocessor... gcc -E
> 	yes
> 	checking whether to enable garbage collector friendliness... no
> 	checking whether to disable memory pools... no
> 	checking for gcc... (cached) gcc
> 
> This lonesome "yes" needs a correction.

To what? Where does it belong? Maybe it's delayed output from some
previous test? Are you seeing breakage in glib itself, or just another
weird bit of output? I think you're expecting configure to be a useful
and clean set of information for end-users. It's not, it's just *brief
and often superficial* notes about how the build will be done and what
external information is being gathered. There are dozens, maybe
thousands of tests that are hacked together but aren't formalized with
standard output (or any output at all)...no harm.

> 	checking whether va_lists can be copied by value... yes
> 	checking for dlopen... yes
> 	checking for dlsym... yes
> 	/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: unknown flag: - 
> export-dynamic
> 	collect2: ld returned 1 exit status
> 	checking for RTLD_GLOBAL brokenness... no
> 	checking for preceeding underscore in symbols... no
> 	checking for dlerror... yes
> 
> I also think that "preceeding" is a typo?

Yup. Doesn't affect anything, don't care enough to fix it and have to
keep that fix in sync with each new release into the future.

The *only* issue I see in your output is the one you didn't
mention...the unknown flag thing that doesn't look like a normal
configure test at all. It's a known weirdness in the glib flag
handling (it's passed correctly but a configure test mis-reads it...if
we pass it so the configure test is clean, the flag itself is wrong in
the real build process).

dan

-- 
Daniel Macks
[email protected]
http://www.netspace.org/~dmacks


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have 
the opportunity to enter the BlackBerry Developer Challenge. See full prize 
details at: http://p.sf.net/sfu/blackberry