Opened 12 years ago
Closed 9 years ago
#38001 closed defect (fixed)
tiff should not install its config.h
| Reported by: | jeremyhu (Jeremy Huddleston Sequoia) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.1.3 |
| Keywords: | Cc: | cooljeanius (Eric Gallager) | |
| Port: | tiff evince |
Description
I noticed the following when installing evince:
CC tiff2ps.lo
In file included from tiff2ps.c:46:
In file included from ./tiff2ps.h:21:
In file included from /opt/local/include/tiffio.h:33:
In file included from /opt/local/include/tiff.h:30:
/opt/local/include/tiffconf.h:27:9: warning: 'SIZEOF_LONG' macro redefined
#define SIZEOF_LONG 4
^
../../config.h:161:9: note: previous definition is here
#define SIZEOF_LONG 8
^
1 warning generated.
CCLD libtiffdocument.la
GEN tiffdocument.evince-backend
Found cached translation database
1) tiff should probably me muniversal, so it pickes up the correct SIZEOF_LONG on each slice rather than doing its ed hackery
2) It looks like evince has the wrong SIZEOF_LONG when +universal
Change History (10)
comment:1 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
| Owner: | changed from macports-tickets@… to jeremyhu@… |
|---|
comment:2 Changed 12 years ago by jmroot (Joshua Root)
comment:3 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
What exactly was the problem that it caused?
comment:4 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to jeremyhu@…:
2) It looks like evince has the wrong SIZEOF_LONG when +universal
Jeremy switched evince to use the muniversal portgroup in r102863 to fix this.
comment:5 Changed 12 years ago by raimue (Rainer Müller)
comment:6 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yeah, the problem is ed scripts can fail silently on an upgrade. I'll update this to a patch and revert muniversal when I get some cycles.
comment:7 Changed 12 years ago by jmroot (Joshua Root)
The reason for using ed scripts in the first place is that a patch against a config.h generated on e.g. x86_64 won't to apply to one generated on e.g. i386.
comment:8 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
No, I will patch config.h.in like how we do it on xorg-server.
comment:10 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Moving to fixed. I don't have time to make this not muniversal, and nobody else does either it seems =)
Note that muniversal was previously removed in r69700 because some of the logic was wrong when it was used (#25585). It's generally preferable to do a little (correct) ed hackery than to use muniversal anyway, because of the greatly increased complexity it brings (with weird bugs and longer build times).