After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 118708 - could not locate ISO DocBook entities
could not locate ISO DocBook entities
Status: RESOLVED NOTABUG
Product: GARNOME
Classification: Deprecated
Component: general
unspecified
Other opensolaris
: Normal normal
: ---
Assigned To: GARNOME Maintainers
garnome list
Depends on:
Blocks:
 
 
Reported: 2003-07-30 20:52 UTC by neel
Modified: 2005-08-15 01:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
hack to work around case insensitive find and still support case insensitiveness where needed (1001 bytes, patch)
2005-07-06 02:14 UTC, Karsten Bräckelmann
none Details | Review

Description neel 2003-07-30 20:52:02 UTC
gnome/libxml2/files/buildDocBookCatalog has 
found=`find /usr/share/xml -iname "iso*amsb.ent" 2> /dev/null`

should iname be "name" ?
Comment 1 Jens Bech Madsen 2003-08-12 15:43:52 UTC
iname gives a case insensitive match, any reason for it to be case
sensitive?
Comment 2 neel 2003-08-12 21:38:18 UTC
Solaris find does not like '-iname' option

[root@rohaan] / (38)> find / -iname passwd
find: bad option -iname
find: path-list predicate-list
Comment 3 Jens Bech Madsen 2003-09-01 20:20:14 UTC
The matches for the entities on my system are:

/usr/share/sgml/entities/sgml-iso-entities-9573-13.1991/ISOamsb.ent
/usr/share/sgml/entities/sgml-iso-entities-8879.1986/ISOamsb.ent
/usr/share/sgml/entities/xml-iso-entities-8879.1986/ISOamsb.ent

So either the case-insensitive match is needed or at least it should
be changed to "ISO*amsb.ent", depending on whether someone has the
lower case names.

Comment 4 alexander.winston 2004-01-28 06:40:55 UTC
Adding the portability keyword.
Comment 5 Jonas Jonsson 2004-01-28 08:57:44 UTC
This is a typical Linux<->Solaris issue.

Don't know if the original poster was building with garnome, I do
suspect that.

Linux use the GNU versions of tar, md5sum, diff, grep, find, patch etc.
Solaris use the SUN versions.

As a Solaris user running garnome, for each and every new version,
these filenames (ya, ya, program-names) must be changed in order to
build garnome, so that we use the GNU versions during the make. 

I wrote a little mail on the garnome-list 5:th of Jan 2004, where I
kindly asked for an easy fix of this issue, simply add a few lines of
definitions in gar.conf.mk, and the use the defined words in the other
places.

Sure hope it'll be in there before the next release of garnome ;)
Comment 6 Paul Drain 2004-10-15 09:23:23 UTC
Mass re-assign
Comment 7 Karsten Bräckelmann 2005-07-05 18:47:00 UTC
The README explicitly states "A sane GNU tool chain" as prerequisite. There are
other GNUisms which will fail without the GNU tools, AFAIK.

Inclined to close this WONTFIX. NEEDINFO for now.
Comment 8 Karsten Bräckelmann 2005-07-06 02:12:47 UTC
The matches for the entities on my system are:

$ find /usr/share/sgml/ -iname "iso*amsb.ent"
/usr/share/sgml/docbook/yelp/docbook/dtd/ent/iso-amsb.ent
/usr/share/sgml/xml-iso-entities-8879.1986/iso-amsb.ent
/usr/share/sgml/sgml-iso-entities-8879.1986/ISOamsb.ent

So yes, obviously there are systems out there using lower case here...


Anyway, does the following patch work on Solaris and does *not* break the build
for any system that used to run fine till now? Beware, I did not test the patch,
I just tested the find command locally...
Comment 9 Karsten Bräckelmann 2005-07-06 02:14:27 UTC
Created attachment 48700 [details] [review]
hack to work around case insensitive find and still support case insensitiveness where needed
Comment 10 Bob Kashani 2005-07-08 01:45:39 UTC
On Solaris I just add a line to my ~/.bash_profile like this:

PATH=/usr/local/gnu/bin:$PATH   #Replace with your gnu path

Then I never have to worry about it. It's a pretty easy fix.

As guenther, has already stated above GARNOME requires the GNU Tool Chain. It's
a lot easier to use one standard tool chain then to test against every UNIX
flavor's tool chain (none of which use a single standard -> the main reason why
UNIX failed as a platform in the first place).