Opened 11 years ago

Last modified 9 years ago

#40478 new defect

gcc-4.8 (and likely earlier) build incorrectly +universal

Reported by: jeremyhu (Jeremy Huddleston Sequoia) Owned by: larryv (Lawrence Velázquez)
Priority: Normal Milestone:
Component: ports Version: 2.2.0
Keywords: universal leopard Cc: ryandesign (Ryan Carsten Schmidt)
Port: gcc48

Description

I noticed this when trying to build libgcc on a Leopard VM:

/usr/bin/g++-4.2 -arch i386 -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/. -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../include -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libcpp/include -I/opt/local/include -I/opt/local/include -I/opt/local/include  -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libdecnumber -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/../libbacktrace   -I/opt/local/include /opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c -o pointer-set.o
/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c:60: error: integer constant is too large for ‘unsigned long’ type
/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c: In function ‘size_t hash1(const void*, long unsigned int, long unsigned int)’:
/opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/pointer-set.c:60: warning: large integer implicitly truncated to unsigned type

My hunch is that gcc's build system is checking sizeof(long) at configure time for x86_64 and using it for the i386 slice:

configure:5912: /usr/bin/gcc-4.2 -arch i386 -arch x86_64 -o conftest -g    -L/opt/local/lib -Wl,-headerpad_max_install_names 
conftest.c  >&5
configure:5912: $? = 0
configure:5912: ./conftest
configure:5912: $? = 0
configure:5927: result: 8

This needs to be solved in a way similar to how we solve it in X11: http://cgit.freedesktop.org/xorg/xserver/tree/include/dix-config-apple-verbatim.h http://cgit.freedesktop.org/xorg/xserver/tree/include/dix-config.h.in

Attachments (3)

gcc48-leo-pt1.patch (2.2 KB) - added by jeremyhu (Jeremy Huddleston Sequoia) 11 years ago.
initial patch
gcc48-leo-pt2.patch (2.2 KB) - added by larryv (Lawrence Velázquez) 11 years ago.
patch generated against GCC 4.8 source
gcc43-gcc47-leo.patch (11.8 KB) - added by larryv (Lawrence Velázquez) 11 years ago.
patch generated against GCC 4.3 through GCC 4.7 source

Download all attachments as: .zip

Change History (11)

comment:1 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

It looks like this goes back to the GPL2 versions, and assuming it hasn't changed in the mean time, we should be able to add this verbatim:

#if !defined(USED_FOR_TARGET) && defined(__APPLE__)
#undef SIZEOF_LONG
#if __LP64__
#define SIZEOF_LONG 8
#else
#define SIZEOF_LONG 4
#endif

to each of:

gcc/config.in:#undef SIZEOF_LONG
libcpp/config.in:#undef SIZEOF_LONG
libdecnumber/config.in:#undef SIZEOF_LONG
libgomp/config.h.in:#undef SIZEOF_LONG
Version 1, edited 11 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (next) (diff)

comment:2 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

I think the reason we don't see this newer than Leopard is because this is only happening when USED_FOR_TARGET which just picks the first arch (which is x86_64 on SL+ but i386 on Leo)

comment:3 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Owner: changed from mww@… to jeremyhu@…
Status: newassigned

comment:4 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

The GPL2 patch I made mostly applies to the GPL3 gccs, so I should have a blind fix for this.

Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Attachment: gcc48-leo-pt1.patch added

initial patch

comment:5 Changed 11 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

Changed 11 years ago by larryv (Lawrence Velázquez)

Attachment: gcc48-leo-pt2.patch added

patch generated against GCC 4.8 source

Changed 11 years ago by larryv (Lawrence Velázquez)

Attachment: gcc43-gcc47-leo.patch added

patch generated against GCC 4.3 through GCC 4.7 source

comment:6 Changed 11 years ago by larryv (Lawrence Velázquez)

This patch applies your changes directly to GCC 4.8, and this one does so for GCC 4.3 through 4.7.

comment:7 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Cc: jeremyhu@… added; larryv@… removed
Owner: changed from jeremyhu@… to larryv@…
Status: assignednew

I seem to have let this one slip by. Can you push your changes?

comment:8 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added; jeremyhu@… removed

Is this still an issue?

Note: See TracTickets for help on using tickets.