This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Packaging error] c3270/tcl3270/s3270/pr3287/x3270


On Tue, 9 Feb 2010, Peter A. Castro wrote:

On Mon, 8 Feb 2010, Dr. Volker Zell wrote:

Hi

The binaries from the following packages are missing the .exe extension.

 c3270-3.3.4p7-2
 pr3287-3.3.4p7-2
 s3270-3.3.4p7-2
 tcl3270-3.3.4p7-2

Yikes! Hmm...how strange. Ok, I'll fix that. Thanks for the catch!

Ok, I've been investigating just how/why this happened and it seems there's been a change in how some of the automagic executable suffix munging is being done in Cygwin 1.7 versus 1.5.

The makefile has this bit of script in it:

/usr/bin/install -c c3270 $DESTDIR/$BINDIR/c3270

Under Cygwin 1.5, this creates "c3270.exe".
Under Cygwin 1.7, this created "c3270"  (no .exe).

There's been no change in the makefile scripts between releases of these
packages, so this is apparently a change in behaviour in either
/usr/bin/install or Cygwin's magical filename resolver internals.

Yes, I've already dug through the email archives and this has been
discussed before with really no good resolution.  As noted in the
archives, by Corinna (I think?), there's inconsistencies presently, and,
for example, if you add the "-s" option to install it magically creates
"c3270.exe" instead of just plain "c3270" (probably because the "strip"
option invokes the strip command and it just knows it needs to create a
".exe" file).

Moding the makefiles to add a $EXE macro everywhere for these packages
would be a large-ish change and not something I'd really want to have to
perpetuate.  However, I have gone through this "exercise" and will feed
back to the owner some "suggestions" on adding said $EXE macro usage ;-)

But that's not going to happen for this quicky fixup release.  Instead,
I've taken the less intrusive (and arguable magical) approach of adding
"-s" to the install options for program installs (done handily via an
environmental variable override :-).

The following package is using the wrong directory for it's man page:

x3270-3.3.4p7-2

/usr/man/man1/x3270.1 -> /usr/share/man/man1/x3270.1

Documentation from all the above packages should go in unversioned
directories (also for suite3270-3.3.4p7-2).

Hmm....That's a change from before too. Ok, I'll see what I can do about that too.

This, however, I am not going to fix, because I don't view it as my problem to fix.

This appears to be a mis-configuration of the Xorg packages,
specifically, the file /usr/lib/X11/config/Imake.tmpl in package
"xorg-cf-files".

x3270, like many traditional X based applications, uses "imake" to
instantiate an Imakefile and then uses xmkmf to create a Makefile from
that Imakefile.

The man path macro (MANPATH) is being set to "/usr/man", based on the
"SystemManDirectory" macro, which, itself, is set based on the "SystemV4"
macro in the Imake.tmpl file.  It's been a while since I hand-cranked the
"World", but I think this file is created by yet another utility and some
config (Imake.cf perhaps ?).

So, whoever, owns the xorg packages, please update the Imake.tmpl (or
whatever generates it) to set the Man path respectively for Cygwin.

Ciao
 Volker

-- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]