Bug 29867 - [4.3 Regression] building libgfortran fails because of multiple definitions gcc-4.3-20061111
Summary: [4.3 Regression] building libgfortran fails because of multiple definitions g...
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.3.0
: P3 blocker
Target Milestone: 4.3.0
Assignee: Daniel Franke
URL:
Keywords: build
Depends on:
Blocks:
 
Reported: 2006-11-16 08:51 UTC by Jean-Pierre Vial
Modified: 2007-01-06 11:11 UTC (History)
7 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2006-12-20 23:01:03


Attachments
stdlib.h and bits/stdlib.h Linux Suse 10.1 amd64 (9.58 KB, application/x-gzip)
2006-11-16 15:27 UTC, Jean-Pierre Vial
Details
all include files with conflicts in libgfortran for x86_64 (amd64) linux (10.54 KB, application/x-gzip)
2006-11-21 17:30 UTC, Jean-Pierre Vial
Details
Includes as requested by Daniel (20.83 KB, application/x-gzip)
2006-12-21 09:10 UTC, Roger Hill-Cottingham
Details
new conflicting includes (22.59 KB, application/x-gzip)
2006-12-21 21:00 UTC, Jean-Pierre Vial
Details
complet error message x86_64 suse linux 10.1 (23.72 KB, application/x-gzip)
2006-12-22 19:20 UTC, Jean-Pierre Vial
Details
fixincludes: find headers in distro-specfic paths (2.14 KB, patch)
2006-12-23 17:53 UTC, Daniel Franke
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Pierre Vial 2006-11-16 08:51:07 UTC
linking libgfortran fails becaus of multiple definitions.
Here are le last lines of error messages. there are several hundred such lines

/usr/include/stdlib.h:342: multiple definition of `strtoul'
.libs/environ.o:/usr/include/stdlib.h:342: first defined here
.libs/in_unpack_generic.o: In function `strtol':
/usr/include/stdlib.h:336: multiple definition of `strtol'
.libs/environ.o:/usr/include/stdlib.h:336: first defined here
.libs/in_unpack_generic.o: In function `strtod':
/usr/include/stdlib.h:330: multiple definition of `strtod'
.libs/environ.o:/usr/include/stdlib.h:330: first defined here
.libs/in_unpack_generic.o: In function `atoi':
/usr/include/stdlib.h:403: multiple definition of `atoi'
.libs/environ.o:/usr/include/stdlib.h:403: first defined here
.libs/in_unpack_generic.o: In function `strtol':
/usr/include/stdlib.h:336: multiple definition of `atol'
.libs/environ.o:/usr/include/stdlib.h:336: first defined here
.libs/in_unpack_generic.o: In function `strtoll':
/usr/include/stdlib.h:384: multiple definition of `atoll'
.libs/environ.o:/usr/include/stdlib.h:384: first defined here
.libs/in_unpack_generic.o: In function `strtod':
/usr/include/stdlib.h:330: multiple definition of `atof'
.libs/environ.o:/usr/include/stdlib.h:330: first defined here
collect2: ld returned 1 exit status
make[3]: *** [libgfortran.la] Erreur 1

This problem did not exist in the previous edition of gcc-4.3
it is new in 20061111
Comment 1 Richard Biener 2006-11-16 11:50:28 UTC
This is because of the C99 inline changes and your glibc.

2006-11-07  Richard Guenther  <rguenther@suse.de>

        * inclhack.def (glibc_c99_inline_2): Adjust for glibc 2.3
        systems.
        * fixincl.x: Regenerate.

and

2006-11-02  Geoffrey Keating  <geoffk@apple.com>

        * inclhack.def (glibc_c99_inline_1): New.
        * inclhack.def (glibc_c99_inline_2): New.
        * inclhack.def (glibc_c99_inline_3): New.
        * inclhack.def (glibc_c99_inline_4): New.
        * fixincl.x: Regenerate.
        * tests/base/bits/string2.h: New.
        * tests/base/sys/sysmacros.h: New.
        * tests/base/sys/stat.h: Update.

were supposed to fix it.  Please provide your stdlib.h header and/or glibc version.
Comment 2 Jean-Pierre Vial 2006-11-16 15:19:56 UTC
Subject: Re:  building libgfortran fails because of
 multiple definitions gcc-4.3-20061111

rguenth at gcc dot gnu dot org wrote:
> ------- Comment #1 from rguenth at gcc dot gnu dot org  2006-11-16 11:50 -------
> This is because of the C99 inline changes and your glibc.
> 
> 2006-11-07  Richard Guenther  <rguenther@suse.de>
> 
>         * inclhack.def (glibc_c99_inline_2): Adjust for glibc 2.3
>         systems.
>         * fixincl.x: Regenerate.
> 
> and
> 
> 2006-11-02  Geoffrey Keating  <geoffk@apple.com>
> 
>         * inclhack.def (glibc_c99_inline_1): New.
>         * inclhack.def (glibc_c99_inline_2): New.
>         * inclhack.def (glibc_c99_inline_3): New.
>         * inclhack.def (glibc_c99_inline_4): New.
>         * fixincl.x: Regenerate.
>         * tests/base/bits/string2.h: New.
>         * tests/base/sys/sysmacros.h: New.
>         * tests/base/sys/stat.h: Update.
> 
> were supposed to fix it.  Please provide your stdlib.h header and/or glibc
> version.
> 
> 
here is /usr/include/stdlib.h and /usr/include/bits/stdlib.h (as tar.gz)

Comment 3 Jean-Pierre Vial 2006-11-16 15:27:35 UTC
Created attachment 12631 [details]
stdlib.h and bits/stdlib.h Linux Suse 10.1 amd64

from linux Suse/Novell 10.1, amd64 version
Comment 4 Jean-Pierre Vial 2006-11-16 15:36:24 UTC
(In reply to comment #1)
> This is because of the C99 inline changes and your glibc.
> 
>
> Please provide your stdlib.h header and/or glibc
> version.
> 
glibc-2.4-31.1  
(Suse/Novell 10.1, x86_64)
Comment 5 Roger Hill-Cottingham 2006-11-20 09:34:08 UTC
I see this too on Gentoo Linux x86_64. The libraries on my system are identical to those posted.

roger@hertz ~ $ uname -a
Linux hertz 2.6.17-gentoo-r4 #1 SMP Thu Aug 24 16:20:25 BST 2006 x86_64 AMD Opteron(tm) Processor 844 GNU/Linux
roger@hertz ~ $ /lib/libc.so.6 
GNU C Library development release version 2.4, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9).
Compiled on a Linux 2.6.11 system on 2006-10-13.
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        GNU libio by Per Bothner
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc core.
        BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

On i686 with the same glibc version, this problem does not exist.

If you need help with testing patches on x86_64, let me know.
Comment 6 Jean-Pierre Vial 2006-11-21 17:30:35 UTC
Created attachment 12664 [details]
all include files with conflicts in libgfortran for x86_64 (amd64) linux
Comment 7 Daniel Franke 2006-12-01 11:41:59 UTC
*** Bug 30008 has been marked as a duplicate of this bug. ***
Comment 8 Ron Hutnik 2006-12-03 04:55:44 UTC
 
I am using gcc-4.3 1202, also 2.17.x headers. glibc 2.5

I get this on a few programs didn't build with emerge -e system (gentoo distro) amd64(core2) and multilib environment.

sys-libs/timezone-data-2006p, this *** did *** when using "-fno-inline", also looking over the build like, --std=c99 was used.
sys-apps/coreutils-6.6 "-fno-inline" NOT work here, cmdline uses 'gnu99'  using -std=gnu89 it compiles, config scripts still see things at c99 compliant, don't know what problems that may cause, just talking here about them compiling.
net-misc/rsync-2.6.9 uses -std=gnu99, if I override that with -std=gnu89 it compiles.
net-misc/openssh-4.5_p1 using --std=c89 not help here as I think the build is pulling in a another lib (randlib) not compiled the same?  <insert guess here>
=========
From looking over the stdlib.h
Seems its uses __USE_ISOC99 define. there is two name spaces used.  __[BEGIN|END] NAMESPACE_STD and __[BEGIN|END]_NAMESPACE_C99

Could these both defined and thus pulling in multiple definitions?  what about amd64/x86 headers at the same time?

I am proposing idea from ignorance, to hopefully a 'dumb' questions triggers thought.

Thank you.
-Ron
Comment 9 Ron Hutnik 2006-12-03 04:58:23 UTC
 
I am using gcc-4.3 1202, also 2.17.x headers. glibc 2.5

I get this on a few programs didn't build with emerge -e system (gentoo distro) amd64(core2) and multilib environment.

sys-libs/timezone-data-2006p, this *** did *** when using "-fno-inline", also looking over the build like, --std=c99 was used.
sys-apps/coreutils-6.6 "-fno-inline" NOT work here, cmdline uses 'gnu99'  using -std=gnu89 it compiles, config scripts still see things at c99 compliant, don't know what problems that may cause, just talking here about them compiling.
net-misc/rsync-2.6.9 uses -std=gnu99, if I override that with -std=gnu89 it compiles.
net-misc/openssh-4.5_p1 using --std=c89 not help here as I think the build is pulling in a another lib (randlib) not compiled the same?  <insert guess here>
=========
From looking over the stdlib.h
Seems its uses __USE_ISOC99 define. there is two name spaces used.  __[BEGIN|END] NAMESPACE_STD and __[BEGIN|END]_NAMESPACE_C99

Could these both defined and thus pulling in multiple definitions?  what about amd64/x86 headers at the same time?

I am proposing idea from ignorance, to hopefully a 'dumb' questions triggers thought.

Thank you.
-Ron
Comment 10 Daniel Franke 2006-12-07 15:11:20 UTC
Here on debian, the last revision that successfully bootstrapped was r118355 (glibc-2.3.2, kernel-2.6.15.7).

Anything else I can do? 
Comment 11 Daniel Franke 2006-12-14 21:41:22 UTC
In reply to comment #1:
Hack "glibc_c99_inline_2" was meant to fix sys/stat.h: but while I have a fixed $(top_builddir)/gcc/include/sys/stat.h on i686, there is no such file on x86_64. 

These commands where run on x86_64:

$> find /usr -name stat.h
/usr/include/asm/stat.h
/usr/include/sys/stat.h                <----
/usr/include/bits/stat.h
/usr/include/linux/stat.h
/usr/include/i386-linux/asm/stat.h
/usr/include/x86_64-linux/sys/stat.h   <----
/usr/include/x86_64-linux/bits/stat.h
/usr/include/i486-linux/sys/stat.h
/usr/include/i486-linux/bits/stat.h

$> grep "extern __inline__ int" /usr/include/sys/stat.h
[no output]

$> grep "extern __inline__ int" /usr/include/x86_64-linux/sys/stat.h
extern __inline__ int stat (__const char *__path,
[6 more lines snipped]

("extern __inline__ int" is the SELECT statement in fix glibc_c99_inline_2)

For me, compilation bails out because of header files included from /usr/include/x86_64-linux/. 


Below, a verbose log of `make stmp-fixinc` (pwd=$(top_builddir)/gcc):

$> rm -rf include/ stmp-fixinc
$> VERBOSE=9
$> make stmp-fixinc
rm -rf include; mkdir include
chmod a+rx include
if [ -d ../prev-gcc ]; then \
  cd ../prev-gcc && \
  make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
    libsubdir=. ; \
else \
  (TARGET_MACHINE='x86_64-pc-linux-gnu'; srcdir=`cd ../../../svn/gcc-head/gcc; ${PWDCMD-pwd}`; \
    SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
    export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
    cd ../build-x86_64-linux/fixincludes && \
    /bin/sh ./fixinc.sh ../../gcc/include \
      `echo /usr/include | sed -e :a -e "s,[^/]*/\.\.\/,," -e ta`  ); \
  rm -f include/syslimits.h; \
  if [ -f include/limits.h ]; then \
    mv include/limits.h include/syslimits.h; \
  else \
    cp ../../../svn/gcc-head/gcc/gsyslimits.h include/syslimits.h; \
  fi; \
fi
Fixing headers into /data/home/daniel/svn-build/gcc-head/gcc/include for x86_64-pc-linux-gnu target
Forbidden identifiers: linux unix
Finding directories and links to directories
 Searching /usr/include/.
 Searching /usr/include/./X11
 Searching /usr/include/./mpi
 Searching /usr/include/./i386-linux/linux
 Searching /usr/include/./i386-linux/asm-generic
Making symbolic directory links
Fixing directory /usr/include into /data/home/daniel/svn-build/gcc-head/gcc/include
Applying io_quotes_def            to asm/apicdef.h
Applying io_quotes_use            to asm/mtrr.h
Applying glibc_c99_inline_4       to sys/sysmacros.h
Applying glibc_c99_inline_3       to bits/string2.h
Applying io_quotes_use            to linux/dn.h
Applying io_quotes_use            to linux/fd.h
Applying io_quotes_use            to linux/fs.h
Applying io_quotes_use            to linux/raid/md_u.h
Applying io_quotes_use            to linux/umsdos_fs.h
Applying io_quotes_use            to linux/atmbr2684.h
Applying io_quotes_use            to linux/nbd.h
Applying io_quotes_use            to linux/raw.h
Applying io_quotes_use            to linux/auto_fs4.h
Applying io_quotes_use            to linux/i2o-dev.h
Applying io_quotes_use            to linux/if_pppox.h
Applying io_quotes_def            to linux/ppp-comp.h
Applying io_quotes_def            to linux/completion.h
Applying io_quotes_def            to linux/soundcard.h
Applying io_quotes_def            to linux/netfilter_ipv4/ip_conntrack_tuple.h
Applying io_quotes_use            to linux/ite_gpio.h
Applying io_quotes_use            to linux/uinput.h
Applying io_quotes_def            to linux/isapnp.h
Applying machine_name             to linux/flat.h
Fixed:  linux/flat.h
Applying io_quotes_use            to linux/random.h
Applying io_quotes_use            to linux/ipmi.h
Applying io_quotes_use            to linux/jffs.h
Applying io_quotes_use            to linux/dm-ioctl-v1.h
Applying io_quotes_use            to linux/dm-ioctl-v4.h
Applying io_quotes_use            to linux/agpgart.h
Applying io_quotes_use            to linux/auto_fs.h
Applying io_quotes_use            to linux/watchdog.h
Applying io_quotes_def            to linux/reiserfs_fs.h
Applying io_quotes_use            to linux/reiserfs_fs.h
Applying io_quotes_def            to linux/modsetver.h
Applying io_quotes_use            to linux/cciss_ioctl.h
Applying io_quotes_use            to linux/blkpg.h
Applying io_quotes_use            to linux/synclink.h
Applying machine_name             to linux/a.out.h
Fixed:  linux/a.out.h
Applying io_quotes_def            to linux/version.h
Applying io_quotes_use            to linux/input.h
Applying io_quotes_use            to linux/ppdev.h
Applying io_quotes_use            to linux/devfs_fs.h
Applying io_quotes_def            to i386-linux/asm/apicdef.h
Applying io_quotes_use            to i386-linux/asm/mtrr.h
Applying avoid_wchar_t_type       to intel-icc64-8.1/stddef.h
Fixed:  intel-icc64-8.1/stddef.h
Applying avoid_wchar_t_type       to intel-icc64-9.0/stddef.h
Fixed:  intel-icc64-9.0/stddef.h
Applying sun_malloc               to malloc.h
Applying stdio_va_list_clients    to curses.h
Applying stdio_stdarg_h           to stdio.h
Applying stdio_va_list            to stdio.h
Fixed:  stdio.h
Applying avoid_wchar_t_type       to intel-icc-9.0/stddef.h
Fixed:  intel-icc-9.0/stddef.h
Applying io_quotes_use            to x86_64-linux/sys/raw.h
Applying io_quotes_use            to x86_64-linux/sys/mount.h
Applying ctrl_quotes_def          to x86_64-linux/readline/chardefs.h
Applying io_quotes_use            to i486-linux/sys/raw.h
Applying io_quotes_use            to i486-linux/sys/mount.h
Applying stdio_va_list_clients    to wchar.h
Applying io_quotes_use            to valgrind/vki-linux.h
Applying sysv68_string            to string.h
Fixing directory /usr/include/X11 into /data/home/daniel/svn-build/gcc-head/gcc/include/root/usr/X11R6/include/X11
Fixing directory /usr/include/mpi into /data/home/daniel/svn-build/gcc-head/gcc/include/root/etc/alternatives/mpi
Cleaning up unneeded directories:
fixincludes is done
chmod a+r include/syslimits.h
echo timestamp > stmp-fixinc
Comment 12 Daniel Franke 2006-12-20 23:01:03 UTC
Jean-Pierre, Roger, 
could you please add the following files to your attachments of this PR (or send them by private mail):
 * /usr/include/features.h
 * /usr/include/sys/stat.h
 * /usr/include/bits/string2.h
 * /usr/include/sys/sysmacros.h

If there are other instances of, say features.h (as shown in comment #11), please add them as well. Please preserve the directory structure as you did with the current attachments - thanks.

    Daniel
Comment 13 Roger Hill-Cottingham 2006-12-21 09:10:17 UTC
Created attachment 12830 [details]
Includes as requested by Daniel

Various include files as requested by Daniel in comment number 12.
Comment 14 Jean-Pierre Vial 2006-12-21 21:00:44 UTC
Created attachment 12832 [details]
new conflicting includes

the requested files, plus /usr/include/bits/stdio.h
all variants existing in the system are included
Comment 15 Daniel Franke 2006-12-21 21:13:08 UTC
Jean-Pierre, thanks for this.
While my conjecture [1] was correct for Roger's files, those you attached seem to pose another problem. I will investigate further ...

[1] http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01520.html
Comment 16 Jean-Pierre Vial 2006-12-22 19:20:18 UTC
Created attachment 12836 [details]
complet error message x86_64 suse linux 10.1

in case it may help, here is the list of 
conflicting files (latest gcc-4.3: 20061216)
/usr/include/bits/mathinline.h
/usr/include/bits/sigset.h
/usr/include/bits/stdio.h
/usr/include/bits/string2.h
/usr/include/ctype.h
/usr/include/stdlib.h
/usr/include/sys/stat.h
/usr/include/sys/sysmacros.h
extracted from the error file using :
grep -o -P '^\/.+\.h' erreur |sort -u
Comment 17 Daniel Franke 2006-12-23 17:53:48 UTC
Created attachment 12839 [details]
fixincludes: find headers in distro-specfic paths

 * fixincl.c(fix_applies): Use fnmatch instead of strstr to allow 
   shell-like wildcard pattern matching.
 * inclhack.def(glibc_c99_inline_[1234]): Add search patterns to file list.
 * fixincl.x: Regenerated.
Comment 18 Roger Hill-Cottingham 2007-01-02 01:14:18 UTC
(In reply to comment #17)
> Created an attachment (id=12839) [edit]
> fixincludes: find headers in distro-specfic paths

Sorry about the delay in replying.

I can confirm that with this patch I can now bootstrap successfully:

                === gfortran Summary ===

# of expected passes            15820
# of expected failures          7
# of unsupported tests          17
/home/roger/src/gcc-svn/build_amber/gcc/testsuite/gfortran/../../gfortran  version 4.3.0 20070101 (experimental)

Thanks very much, I really appreciate your hard work.

Roger.
Comment 19 Daniel Franke 2007-01-06 11:11:40 UTC
Resolved in private mail to difficulties with the build process.
Although PR30008 gave the same error messages, it is not a dupe.