Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suspicious Configure output #12123

Closed
p5pRT opened this issue May 21, 2012 · 12 comments
Closed

Suspicious Configure output #12123

p5pRT opened this issue May 21, 2012 · 12 comments

Comments

@p5pRT
Copy link

p5pRT commented May 21, 2012

Migrated from rt.perl.org#113024 (status was 'resolved')

Searchable as RT113024$

@p5pRT
Copy link
Author

p5pRT commented May 21, 2012

From @mauke

Created by @mauke

While configuring 5.16.0 I noticed the following two messages about
$libdb_needs_pthread and #ifdef​:

================================================================================
Stripping down executable paths...

Creating config.sh...
Hmm...You had some extra variables I don't know about...I'll try to keep 'em...
  Propagating recommended variable $libdb_needs_pthread...

If you'd like to make any changes to the config.sh file before I begin
to configure things, do it as a shell escape now (e.g. !vi config.sh).

and

================================================================================
Guessing which symbols your C compiler and preprocessor define...
try.c​: In function 'main'​:
try.c​:5785​:17​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5788​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5791​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5794​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5821​:17​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5824​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5827​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5830​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5857​:17​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5860​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5863​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5866​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5893​:16​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5896​:17​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5899​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5902​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5929​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5932​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5935​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:5938​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6769​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6772​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6775​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6778​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6805​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6808​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6811​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6814​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6841​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6844​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6847​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6850​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6877​:17​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6880​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6883​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6886​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6913​:19​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6916​:20​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6919​:21​: warning​: extra tokens at end of #ifdef directive [enabled by default]
try.c​:6922​:21​: warning​: extra tokens at end of #ifdef directive [enabled by default]
Your C pre-processor defines the following symbols​:

Is this normal?

Perl Info

Flags:
    category=install
    severity=low

Site configuration information for perl 5.16.0:

Configured by mauke at Mon May 21 11:48:30 CEST 2012.

Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=2.6.38-gentoo-r6, archname=i686-linux
    uname='linux nora 2.6.38-gentoo-r6 #1 preempt sat aug 6 03:05:34 cest 2011 i686 amd athlon(tm) 64 processor 3200+ authenticamd gnulinux '
    config_args='-de -Dprefix=/home/mauke/usr/perlbrew/perls/perl-5.16.0'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.6.3', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.14.1.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.14.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.16.0:
    /home/mauke/usr/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0/i686-linux
    /home/mauke/usr/perlbrew/perls/perl-5.16.0/lib/site_perl/5.16.0
    /home/mauke/usr/perlbrew/perls/perl-5.16.0/lib/5.16.0/i686-linux
    /home/mauke/usr/perlbrew/perls/perl-5.16.0/lib/5.16.0
    .


Environment for perl 5.16.0:
    HOME=/home/mauke
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=POSIX
    LD_LIBRARY_PATH=/home/mauke/usr/local/lib
    LOGDIR (unset)
    PATH=/home/mauke/usr/perlbrew/bin:/home/mauke/usr/perlbrew/perls/perl-5.16.0/bin:/home/mauke/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.4.5:/opt/sun-jdk-1.4.2.13/bin:/opt/sun-jdk-1.4.2.13/jre/bin:/opt/sun-jdk-1.4.2.13/jre/javaws:/opt/dmd/bin:/usr/games/bin
    PERLBREW_HOME=/home/mauke/.perlbrew
    PERLBREW_PATH=/home/mauke/usr/perlbrew/bin:/home/mauke/usr/perlbrew/perls/perl-5.16.0/bin
    PERLBREW_PERL=perl-5.16.0
    PERLBREW_ROOT=/home/mauke/usr/perlbrew
    PERLBREW_VERSION=0.27
    PERL_BADLANG (unset)
    PERL_UNICODE=SAL
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented May 22, 2012

From @jkeenan

On Mon May 21 03​:45​:24 2012, l.mai@​web.de wrote​:

This is a bug report for perl from l.mai@​web.de,
generated with the help of perlbug 1.39 running under perl 5.16.0.

Is this normal?

Can you provide the full command and options you used for 'sh ./Configure'?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented May 22, 2012

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented May 29, 2012

From @mauke

On 2012-05-21 James E Keenan via RT wrote​:

On Mon May 21 03​:45​:24 2012, l.mai@​web.de wrote​:

This is a bug report for perl from l.mai@​web.de,
generated with the help of perlbug 1.39 running under perl 5.16.0.

Is this normal?

Can you provide the full command and options you used for
'sh ./Configure'?

% ./Configure -de

@p5pRT
Copy link
Author

p5pRT commented May 29, 2012

From @jkeenan

On Tue May 29 05​:24​:57 2012, l.mai@​web.de wrote​:

On 2012-05-21 James E Keenan via RT wrote​:

On Mon May 21 03​:45​:24 2012, l.mai@​web.de wrote​:

This is a bug report for perl from l.mai@​web.de,
generated with the help of perlbug 1.39 running under perl 5.16.0.

Is this normal?

Can you provide the full command and options you used for
'sh ./Configure'?

% ./Configure -de

Can we assume that the machine on which you noted this suspicious output
is that from which you filed the bug report? (I.e., are you on a 64-bit
Linux using cc=gcc v4.6.3, etc.?)

I don't have access to a 64-bit machine and my highest version of gcc is
4.3.2. So I doubt I'd see the same warnings as you have. This is what
I saw when I logged the output from 'sh ./Configure -de'​:

#####
1854 Determining whether we can use sysctl with KERN_PROC_PATHNAME to
find executing program...
1855 try.c​: In function 'main'​:
1856 try.c​:22​: error​: 'KERN_PROC' undeclared (first use in this function)
1857 try.c​:22​: error​: (Each undeclared identifier is reported only once
1858 try.c​:22​: error​: for each function it appears in.)
1859 try.c​:23​: error​: 'KERN_PROC_PATHNAME' undeclared (first use in this
function)
1860 I'm unable to compile the test program.
1861 I'll assume no sysctl with KERN_PROC_PATHNAME here.
1862
1863 Determining whether we can use _NSGetExecutablePath to find
executing program...
1864 try.c​:4​:25​: error​: mach-o/dyld.h​: No such file or directory
1865 try.c​: In function 'main'​:
1866 try.c​:13​: error​: 'uint32_t' undeclared (first use in this function)
1867 try.c​:13​: error​: (Each undeclared identifier is reported only once
1868 try.c​:13​: error​: for each function it appears in.)
1869 try.c​:13​: error​: expected ';' before 'size'
1870 try.c​:25​: error​: 'size' undeclared (first use in this function)
1871 I'm unable to compile the test program.
1872 I'll assume no _NSGetExecutablePath here.
...
2094 Creating config.sh...
2095 Hmm...You had some extra variables I don't know about...I'll try to
keep 'em...
2096 Propagating recommended variable $libdb_needs_pthread...
2097
#####

So, I saw a different set of error messages from 'try.c' from yours --
but this didn't impede a successful configuration, build, test or
installation. And I got exactly the same "extra variables" message as
you did.

So I don't think you have anything big to worry about. Perhaps someone
more knowledgeable than I concerning Configure could say something more
about 'try.c'.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2012

From @mauke

On 2012-05-29 James E Keenan via RT wrote​:

Can we assume that the machine on which you noted this suspicious
output is that from which you filed the bug report? (I.e., are you
on a 64-bit Linux using cc=gcc v4.6.3, etc.?)

Yes, but it's a 32-bit Linux (and it also happens with gcc 4.7.0).

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2012

From @jkeenan

On 6/1/12 11​:13 AM, Lukas Mai wrote​:

On 2012-05-29 James E Keenan via RT wrote​:

Can we assume that the machine on which you noted this suspicious
output is that from which you filed the bug report? (I.e., are you
on a 64-bit Linux using cc=gcc v4.6.3, etc.?)

Yes, but it's a 32-bit Linux (and it also happens with gcc 4.7.0).

Okay. As I wrote previously, if this is not preventing you from
successfully building, testing and installing Perl 5, then I don't think
you have much to worry about.

But I hope some of our configuration experts can shed some light on what
'try.c' does and how we might eliminate or reduce spurious warnings.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2012

From @doughera88

On Tue, 29 May 2012, James E Keenan via RT wrote​:

On Tue May 29 05​:24​:57 2012, l.mai@​web.de wrote​:

On 2012-05-21 James E Keenan via RT wrote​:

On Mon May 21 03​:45​:24 2012, l.mai@​web.de wrote​:

This is a bug report for perl from l.mai@​web.de,
generated with the help of perlbug 1.39 running under perl 5.16.0.

Is this normal?

: Creating config.sh...
: Hmm...You had some extra variables I don't know about...I'll try to keep 'em...
: Propagating recommended variable $libdb_needs_pthread...

Yes, that's normal and not a problem. It's defined in the hints file,
so Configure doesn't know about it. You can safely ignore it.

: ===========================================================================
: Guessing which symbols your C compiler and preprocessor define...
: try.c​: In function 'main'​:
: try.c​:5785​:17​: warning​: extra tokens at end of #ifdef directive [enabled by default]
: try.c​:5788​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]

[ and many more similar ones ]

I don't recognize this one, and can't figure out what those extra
tokens might be. If you could pause Configure at that point (maybe
edit it to put an 'exit' before the '$rm_try' command) and then
look at UU/try.c we could try to figure out what's going wrong.

However, I really doubt it's a real problem. The test is trying to
guess which symbols are predefined by the compiler, but the results of
the test are never used, so it doesn't matter whether the tests
succeed or fail. They are old leftovers.

Can you provide the full command and options you used for
'sh ./Configure'?

% ./Configure -de

Can we assume that the machine on which you noted this suspicious output
is that from which you filed the bug report? (I.e., are you on a 64-bit
Linux using cc=gcc v4.6.3, etc.?)

I don't have access to a 64-bit machine and my highest version of gcc is
4.3.2. So I doubt I'd see the same warnings as you have. This is what
I saw when I logged the output from 'sh ./Configure -de'​:

#####
1854 Determining whether we can use sysctl with KERN_PROC_PATHNAME to
find executing program...
1855 try.c​: In function 'main'​:
1856 try.c​:22​: error​: 'KERN_PROC' undeclared (first use in this function)
1857 try.c​:22​: error​: (Each undeclared identifier is reported only once
1858 try.c​:22​: error​: for each function it appears in.)
1859 try.c​:23​: error​: 'KERN_PROC_PATHNAME' undeclared (first use in this
function)
1860 I'm unable to compile the test program.
1861 I'll assume no sysctl with KERN_PROC_PATHNAME here.
1862
1863 Determining whether we can use _NSGetExecutablePath to find
executing program...
1864 try.c​:4​:25​: error​: mach-o/dyld.h​: No such file or directory
1865 try.c​: In function 'main'​:
1866 try.c​:13​: error​: 'uint32_t' undeclared (first use in this function)
1867 try.c​:13​: error​: (Each undeclared identifier is reported only once
1868 try.c​:13​: error​: for each function it appears in.)
1869 try.c​:13​: error​: expected ';' before 'size'
1870 try.c​:25​: error​: 'size' undeclared (first use in this function)
1871 I'm unable to compile the test program.
1872 I'll assume no _NSGetExecutablePath here.

Those are all harmless. Configure tries lots of things as it tries to
find something that works. You shouldn't see them, however. I
suspect someone (possibly me) cut & pasted a $compile_ok instead of a
$compile command (which would hide the messages).

So I don't think you have anything big to worry about. Perhaps someone
more knowledgeable than I concerning Configure could say something more
about 'try.c'.

Agreed. There's nothing to worry about here.

Thanks for keeping on top of these tickets!

--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Jun 4, 2012

From @mauke

On 2012-06-01 Andy Dougherty via RT wrote​:

I don't recognize this one, and can't figure out what those extra
tokens might be. If you could pause Configure at that point (maybe
edit it to put an 'exit' before the '$rm_try' command) and then
look at UU/try.c we could try to figure out what's going wrong.

I did that, and the bad directives look like this​:

...
#ifdef __INT16_C(c)
printf("__INT16_C(c)=%s\n", STRINGIFY(__INT16_C(c)));
#endif
#ifdef ___INT16_C(c)
printf("___INT16_C(c)=%s\n", STRINGIFY(___INT16_C(c)));
#endif
#ifdef ____INT16_C(c)
printf("____INT16_C(c)=%s\n", STRINGIFY(____INT16_C(c)));
#endif
#ifdef ____INT16_C(c)__
printf("____INT16_C(c)__=%s\n", STRINGIFY(____INT16_C(c)__));
#endif
...

The C compiler complains because "__INT16_C(c)" is obviously not a
valid identifier. These macros seem to be coming from 'UU/Cppsym.true'.
They probably got in there via cpp -dM​:

% cpp -dM /dev/null | grep '(c)'
#define __INTMAX_C(c) c ## LL
#define __INT8_C(c) c
#define __INT64_C(c) c ## LL
#define __UINT16_C(c) c
#define __UINT64_C(c) c ## ULL
#define __INT32_C(c) c
#define __UINTMAX_C(c) c ## ULL
#define __UINT8_C(c) c
#define __UINT32_C(c) c ## U
#define __INT16_C(c) c

@p5pRT
Copy link
Author

p5pRT commented Jun 6, 2012

From @doughera88

On Fri, 1 Jun 2012, Andy Dougherty wrote​:

On Tue, 29 May 2012, James E Keenan via RT wrote​:

On Tue May 29 05​:24​:57 2012, l.mai@​web.de wrote​:

On 2012-05-21 James E Keenan via RT wrote​:

On Mon May 21 03​:45​:24 2012, l.mai@​web.de wrote​:

This is a bug report for perl from l.mai@​web.de,
generated with the help of perlbug 1.39 running under perl 5.16.0.

I don't have access to a 64-bit machine and my highest version of gcc is
4.3.2. So I doubt I'd see the same warnings as you have. This is what
I saw when I logged the output from 'sh ./Configure -de'​:

#####
1854 Determining whether we can use sysctl with KERN_PROC_PATHNAME to
find executing program...
1855 try.c​: In function 'main'​:
1856 try.c​:22​: error​: 'KERN_PROC' undeclared (first use in this function)
1857 try.c​:22​: error​: (Each undeclared identifier is reported only once
1858 try.c​:22​: error​: for each function it appears in.)
1859 try.c​:23​: error​: 'KERN_PROC_PATHNAME' undeclared (first use in this
function)
1860 I'm unable to compile the test program.
1861 I'll assume no sysctl with KERN_PROC_PATHNAME here.
1862
1863 Determining whether we can use _NSGetExecutablePath to find
executing program...
1864 try.c​:4​:25​: error​: mach-o/dyld.h​: No such file or directory
1865 try.c​: In function 'main'​:
1866 try.c​:13​: error​: 'uint32_t' undeclared (first use in this function)
1867 try.c​:13​: error​: (Each undeclared identifier is reported only once
1868 try.c​:13​: error​: for each function it appears in.)
1869 try.c​:13​: error​: expected ';' before 'size'
1870 try.c​:25​: error​: 'size' undeclared (first use in this function)
1871 I'm unable to compile the test program.
1872 I'll assume no _NSGetExecutablePath here.

Those are all harmless. Configure tries lots of things as it tries to
find something that works. You shouldn't see them, however. I
suspect someone (possibly me) cut & pasted a $compile_ok instead of a
$compile command (which would hide the messages).

This was fixed by

commit 9e477c1
Author​: Andy Dougherty <doughera@​lafayette.edu>
Date​: Wed Jun 6 09​:07​:11 2012 -0400

  Replace $compile_ok by $compile for two probes that can fail.

I already made corresponding changes to metaconfig with these two commits​:

commit ce92b45824804da828aa9a1cb53d69e1a54e2acc
Author​: Andy Dougherty <doughera@​lafayete.edu>
Date​: Wed Jun 6 08​:58​:29 2012 -0400

  Replace $compile_ok by $compile since it's ok for this probe to fail.
 
commit 351a5dce638b1a893fddcaa289c1050accaee850
Author​: Andy Dougherty <doughera@​lafayete.edu>
Date​: Wed Jun 6 08​:55​:12 2012 -0400

  Replace $compile_ok by $compile since it's ok for this probe to fail.

I'll push the prepocessor patches shortly.
 
--
  Andy Dougherty doughera@​lafayette.edu

@p5pRT
Copy link
Author

p5pRT commented Jun 6, 2012

@cpansprout - Status changed from 'open' to 'resolved'

@p5pRT p5pRT closed this as completed Jun 6, 2012
@p5pRT
Copy link
Author

p5pRT commented Jun 6, 2012

From @doughera88

On Wed, 6 Jun 2012, Andy Dougherty wrote​:

I'll push the prepocessor patches shortly.

The warnings​:

: Guessing which symbols your C compiler and preprocessor define...
: try.c​: In function 'main'​:
: try.c​:5785​:17​: warning​: extra tokens at end of #ifdef directive [enabled by default]
: try.c​:5788​:18​: warning​: extra tokens at end of #ifdef directive [enabled by default]

are now fixed with

commit 6f87f40
Author​: Andy Dougherty <doughera@​lafayette.edu>
Date​: Wed Jun 6 11​:12​:58 2012 -0400

  Configure​: Avoid Cppsym warnings for extra tokens [perl #113024]
 
  The cppsymbols can include macros such as __INT16_C(c), which can't
  be tested with a simple #ifdef. This patch strips off the opening
  parenthesis and everything following it. These macros were generated
  by cpp -dM.
 
  Also ensure Cppsym.true list is sorted for later input to comm.
  (I noticed this while testing this change on Solaris.)

I also pushed the equivalent metaconfig patches

commit 84a69cea86dfdcd6eb2538b1c7870351c617d99a
Author​: Andy Dougherty <doughera@​lafayete.edu>
Date​: Wed Jun 6 11​:11​:34 2012 -0400

  Ensure Cppsym.true list is sorted (for later input to comm).

commit 7bd925e6d5c37ea08d88d74f0c76456744d47b16
Author​: Andy Dougherty <doughera@​lafayete.edu>
Date​: Wed Jun 6 09​:35​:31 2012 -0400

  Avoid Cppsym warnings for extra tokens [perl #113024]
 
  The cppsymbols can include macros such as __INT16_C(c), which can't
  best tested with a simple #ifdef. This patch strips off the opening
  parenthesis and everything following it. These macros were generated
  by cpp -dM.

This should resolve [perl #113024]

--
  Andy Dougherty doughera@​lafayette.edu

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant