Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#17042 closed defect (fixed)

glib2: incorrect glibconfig.h with +universal (i386 x86_64)

Reported by: pguyot (Paul Guyot) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 1.6.0
Keywords: Cc: jmroot (Joshua Root), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), keinstein_junior@…
Port: glib2, glib2-devel

Description (last modified by ryandesign (Ryan Carsten Schmidt))

glib2 port installs an incorrect glibconfig.h file with +universal {i386 x86_64}. The file is created with 64 bits defines, while it should probably feature a #if __LP64__ #else #endif logic.

For example, it has:

typedef signed long gint64;

while this is only true on x86_64.

Attachments (5)

patch-config.h.diff (760 bytes) - added by jmroot (Joshua Root) 15 years ago.
patch-glibconfig.h.diff (1.0 KB) - added by jmroot (Joshua Root) 15 years ago.
glib2-LP64.diff (808 bytes) - added by jmroot (Joshua Root) 15 years ago.
glib2-2.19.6-muniversal.diff (3.7 KB) - added by ryandesign (Ryan Carsten Schmidt) 15 years ago.
glib2-Portfile.diff (6.2 KB) - added by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) 15 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Is that because of the patches I'm applying in the port to make the universal build work in the first place, or is this an upstream problem?

comment:2 Changed 15 years ago by jmroot (Joshua Root)

It seems that the configure patch is no longer necessary, as it's now generated with autoconf 2.63 which handles universal endianness correctly. But the 32/64-bit problems seem to be an upstream bug.

The easiest fix at this point is probably an ed script applied to config.h/glibconfig.h in post-configure, like toby has been using in e.g. r42691.

comment:3 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Port: glib2-devel added

Changed 15 years ago by jmroot (Joshua Root)

Attachment: patch-config.h.diff added

Changed 15 years ago by jmroot (Joshua Root)

Attachment: patch-glibconfig.h.diff added

comment:4 Changed 15 years ago by jmroot (Joshua Root)

Cc: jmr@… added

Attached patches fix this. Also removed the existing patch-configure.diff since things seem to work correctly without it these days.

Changed 15 years ago by jmroot (Joshua Root)

Attachment: glib2-LP64.diff added

comment:5 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Status: newassigned

comment:6 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: mcalhoun@… added

I've now run into this issue personally when trying to build glibmm. If a 4-way glib2 @2.18.3_0+darwin_9+universal is active, it fails to build with:

value_basictypes.cc:224: error: integer constant is too large for 'long' type
value_basictypes.cc:224: error: integer constant is too large for 'long' type
value_basictypes.cc:251: error: integer constant is too large for 'unsigned long' type

If I drop back to a non-universal glib2 @2.18.3_0+darwin_9 it builds fine.

I hoped I could fix glib2 by using the muniversal portgroup instead. First I had to use the config cache to provide answers for four tests it wanted to run a program to figure out (which won't work when cross-compiling). Then the next obstacle was came when the configure script demanded a build-system-native copy of glib-genmarshal in PATH during the configure phase. There wasn't one, of course -- not in PATH, not anywhere -- because nothing gets built until the build phase. I managed to fake out the configure script by creating an empty executable file in the native arch's work path, and adding the path to that directory to the PATH during configure and build. This allowed the port to build and install. (By the non-native build phase, the native glib-genmarshal has already been built.)

Unfortunately, ${prefix}/lib/glib-2.0/include/glibconfig.h is filled with a profusion of nested #if directives which I can't figure out, and neither can, for example, glibmm, which says:

/mp/lib/glib-2.0/include/glibconfig.h:227:2: error: #else after #else
/mp/lib/glib-2.0/include/glibconfig.h:221:1: error: the conditional began here

I'll attach my latest attempt, which is for glib2-devel. Next I'll try using merger_dont_diff on that file.

Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

comment:7 in reply to:  6 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to ryandesign@…:

Next I'll try using merger_dont_diff on that file.

That seems to do it. Updated glib2-devel in r47055.

comment:8 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Attached are proposed modifications to glib2.
It goes beyond the scope of this ticket, but I did not want to parse out the changes into several tickets.

All testing was done using an Leopard/Intel machine and the latest XCode.

Changes:

The version is updated (fixes #18054).

ftp://ftp.gtk.org/pub/${my_name}/${branch}/ seems to be a valid master_site

patch-gutils.c.diff was added in r14022.
config.h (which is included by glib/gutils.c) now defines #define HAVE__NSGETENVIRON 1.

patch-which.diff was added because of #17418.
The glib bug tracker says it is fixed and seems to be on Leopard.

-bind_at_load was added in r7825 with no explanation.
-bind_at_load is already set for some systems in ltmain.sh.

-funroll-loops and -fstrict-aliasing have always been in the Portfile (r1322).
It is not clear why they are needed, and #18384 already requests that -funroll-loops be removed (as it was in r47055).

Somewhere along the line, --mandir became unnecessary.

When the compiler has a -arch option, the configure script looks to "#include <endian.h>" for more information.
It can not find it because file is located at /usr/include/machine/endian.h.

patch-configure.diff was added because of #15816.
The glib bug tracker says it is fixed.

The platform powerpc code was added because of #13973.
Using the muniversal PortGroup, the problem should be fixed.

patch-glib_gutils.h.diff was added because of #13006.
The glib bug tracker says it is fixed.

The universal code is based on r47055, except that

  • --config-cache is used only when needed
  • GLIB_GENMARSHAL is used instead of setting the PATH variable and creating a glib-genmarshal file

I have not yet added the code from r47055 to ensure that ${workpath}/.../gobject/glib-genmarshal actually exists.

NM is set because, for some unknown reason, cross-compiling doesn't try to use it.
This should fix #18575.

comment:9 in reply to:  8 Changed 15 years ago by jmroot (Joshua Root)

Replying to mcalhoun@…:

-funroll-loops and -fstrict-aliasing have always been in the Portfile (r1322).
It is not clear why they are needed, and #18384 already requests that -funroll-loops be removed (as it was in r47055).

They're not *needed*, they are optimisation flags. Strict aliasing improves performance, and the only reason not to use it is if the code relies on type-punning, which will break.

comment:10 in reply to:  8 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to mcalhoun@…:

Attached are proposed modifications to glib2.

Thank you!

It goes beyond the scope of this ticket, but I did not want to parse out the changes into several tickets.

I do like to make separate changes in separate commits, so I will attempt to do so.

ftp://ftp.gtk.org/pub/${my_name}/${branch}/ seems to be a valid master_site

Agreed; reenabling it in glib2 and glib2-devel in r47120.

comment:11 in reply to:  8 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to mcalhoun@…:

patch-which.diff was added because of #17418.
The glib bug tracker says it is fixed and seems to be on Leopard.

patch-which.diff is still necessary.

The upstream bug has allegedly been fixed in the gtk-doc sources and the fix will be included in gtk-doc 1.12. I have been unable to verify the fix because I cannot get gtk-doc to build from trunk. The fix will not appear in glib2 until the people who package glib2 are using a version of gtk-doc that includes the fix.

You will not see the problem on Leopard because the version of "which" on Leopard returns status code 1 if it does not find the program in question. The version of "which" on Tiger and earlier returns status code 0 regardless of whether or not it finds the program in question; this is the behavior that the code in gtk-doc did not anticipate and with which it does not work correctly, because it assumes that if "which" exits with status code 0 then the program in question exists.

Somewhere along the line, --mandir became unnecessary.

Agreed; removing it from glib2 and glib2-devel in r47122.

comment:12 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)

Has duplicate #18756.

comment:13 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Attached is an update of glib2-Portfile.diff.

Changes:

The version is updated (fixes #18054).

patch-gutils.c.diff was added in r14022.
config.h (which is included by glib/gutils.c) now defines #define HAVE__NSGETENVIRON 1.

patch-which.diff was added because of #17418.
The patch is wrapped in an if statement to signify the change of which in Leopard.

-bind_at_load was added in r7825 with no explanation.
-bind_at_load is already set for some systems in ltmain.sh.

-funroll-loops and -fstrict-aliasing have always been in the Portfile (r1322).
#18384 already requests that -funroll-loops be removed (as it was in r47055).

When the compiler has a -arch option, the configure script looks to "#include <endian.h>" for more information.
It can not find it because file is located at /usr/include/machine/endian.h.

patch-configure.diff was added because of #15816.
The glib bug tracker says it is fixed.

The platform powerpc code was added because of #13973.
Using the muniversal PortGroup, the problem should be fixed.

patch-glib_gutils.h.diff was added because of #13006.
The glib bug tracker says it is fixed.

The universal code is based on r47055, except that

  • --config-cache is used only when needed
  • GLIB_GENMARSHAL is used instead of setting the PATH variable and creating a glib-genmarshal file

NM is set because, for some unknown reason, cross-compiling doesn't try to use it.
This should fix #18575.

Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Attachment: glib2-Portfile.diff added

comment:14 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: keinstein_junior@… added

CC reporter of duplicate #18877.

comment:15 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: assignedclosed

Fixed in r49134 (maintainer timeout).

comment:16 Changed 15 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

Note: See TracTickets for help on using tickets.