Re: Cygport support for GCC-4.

Dave Korn wrote:
>   Here are a few mods which I found useful when building GCC-4.  They're
> diff'd against the 1.5-distro version of cygport that I've been working with
> but I could port them up to SVN if they're OK; I see that cygconf() has moved
> to the autotools class file.

Let me preface with this:  Some packages won't be (in cygport terms)
"one-liners".  gcc is certainly complex enough that some of the burden
will need to be carried by the .cygport(5) rather than cygport(1).

At the same time, I'll do what I can to help.  But without looking at
your .cygport and patches to see what you're doing, I'm really a bit in
the dark.  (You can send these privately if you wish.)

>   First up: how about adding "-p" to the diff options?  It makes the
> generated source patches more easily human readable.

Fair enough; I'll go ahead and apply this.

>   Secondly: I need to ship a patched ltmain.sh with GCC-4, so I'd like it to
> be added to the section where automake and libtool get a smaller set of
> default_excludes.  This should be uncontroversial.

Not so fast.   automake and libtool are exceptions here because they
are the original sources of those packages; imagine the case where
libtool's ltmain.sh needed a patch, which would then be deployed for use
in other packages' builds.  All other packages use these only for
building, and hence are automatically updated and therefore ignored.

Re: Cygport support for GCC-4.

Yaakov (Cygwin/X) wrote:
> Dave Korn wrote:
>> Here are a few mods which I found useful when building GCC-4.  They're
>> diff'd against the 1.5-distro version of cygport that I've been working
>> with but I could port them up to SVN if they're OK; I see that cygconf()
>> has moved to the autotools class file.
>
> Let me preface with this:  Some packages won't be (in cygport terms)
> "one-liners".  gcc is certainly complex enough that some of the burden will
> need to be carried by the .cygport(5) rather than cygport(1).

  Yes, of course. I'd like to avoid cut'n'pasting large chunks of cygport(1)
into my .cygport(5) just to make minor tweaks to the functionality, but of
course I can if I have to. I'd rather not because effectively I'd be forking
the cygport(1) code that way. It seems unlikely that the cygport functions I
would override would change their semantics or interactions with other
top-level functions, but maybe some of the internal cygport private functions
they call might change in a future version, so I'd need to maintain the copied
code WRT future cygport updates.

  I'm aware that defining a global (shell) variable to modify the behaviour of
cygconf is ugly; I'd be keen to implement it a better way if you have any
suggestions.

> At the same time, I'll do what I can to help.  But without looking at your
> .cygport and patches to see what you're doing, I'm really a bit in the
> dark.  (You can send these privately if you wish.)

  The only patches I have are the ones attached to that post; the cygport file
as I currently have it is attached here for reference.  (Or did you want the

Re: Cygport support for GCC-4.

Dave Korn wrote:
>   The only patches I have are the ones attached to that post; the cygport file
> as I currently have it is attached here for reference.  (Or did you want the
> src.patch?)

Sorry for not being clear; I meant the src.patch(es).

>   Effectively, GCC is *also* an original source of this file!

Not really, it just uses a forked version that we need to deal with.

>   GCC uses a forked libtool and ltmain.sh is not autogenerated.  Hence I need
> to ship it, and if I want to modify it, I have to make sure the diffs end up
> in the src.patch.

Oh, a forked libtool.  Lovely.  Please tell me they're not still using
some ancient version too.

>   <shrugs>  It is what it is.  fixincludes/configure was accidentally
> regenerated with the wrong version just before the 4.3 branch was cut.  The
> next time it was regenerated it got fixed back to 2.59 on mainline, but by
> then it was too late for 4.3 branch.
> >   Quite possibly so, which is why I sent the patch for discussion.
Maybe I
> should just reconfigure the fixincludes dir with 2.59 and then it won't
> matter, but I can't do that unless I can ship the diffs to the generated
> configure file.  So I guess that if I can have the facility proposed in the
> as-yet-hypothetical fourth patch, I wouldn't need the horrible kludge in the
> third patch.

can't use CYGCONF_ARGS with cygport

Hi everyone,

As I understand, CYGCONF_ARGS can provide additionnals parameters to 
./configure

if I try :
    $ CYGCONF_ARGS='CFLAGS="-g3 -O0"' cygport foo.cygport compile

./configure failed with error message :
configure: error: unrecognized option: -O0"

It seems that the string CFLAGS="-g3 -O0" is split in 2 parameters 
'CFLAGS="-g3' and '-O0"'

you can see that with (as an example, I use xev package):
    $ CYGCONF_ARGS='CFLAGS="-g3 -O0"' bash -xv cygport 
xev-1.0.3-1.cygport compile

...
+ ac_cv_func_mmap_fixed_mapped=yes
+ verbose /e/temp/xev/xev-1.0.3-1/src/xev-1.0.3/configure 
--srcdir=/e/temp/xev/xev-1.0.3-1/src/xev-1.0.3 --prefix=/usr 
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--libexecdir=/usr/sbin --datadir=/usr/share --localstatedir=/var 
--sysconfdir=/etc --datarootdir=/usr/share 
--docdir=/usr/share/doc/xev-1.0.3 'CFLAGS="-g3' '-O0"'
+ echo /e/temp/xev/xev-1.0.3-1/src/xev-1.0.3/configure 
--srcdir=/e/temp/xev/xev-1.0.3-1/src/xev-1.0.3 --prefix=/usr 
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 

Re: can't use CYGCONF_ARGS with cygport

hd wrote:
> As I understand, CYGCONF_ARGS can provide additionnals parameters to 
> ./configure
> 
> if I try :
>     $ CYGCONF_ARGS='CFLAGS="-g3 -O0"' cygport foo.cygport compile
> 
> ./configure failed with error message :
> configure: error: unrecognized option: -O0"
> 
> It seems that the string CFLAGS="-g3 -O0" is split in 2 parameters 
> 'CFLAGS="-g3' and '-O0"'
> 
> I have also tried without success
>     $ CYGCONF_ARGS='CFLAGS=\"-g3 -O0\"' cygport foo.cygport compile

Just set CFLAGS in the foo.cygport or in ~/.cygport.conf.

Yaakov
Cygwin Ports

[Fwd: Bad CRC on setup?]

Every time I try to use Cygwin setup.exe to select Cygwin Ports packages 
I get notification of bad CRC, and it won't allow me to select (or see) 
any Cygwin Ports packages.

A facsimile (damned MS-Lose unavailable text!) of the error message is:

    Mirror Error: Setup.ini signature
    ftp://sourceware.org/pub/cygwinports/setup.bz2.sig from
    ftp://sourceware.org/pub/cygwinports failed to verify.
    Possible corrupt mirror? Setup.ini rejected.

What am I doing wrong?

TIA,

Lee

------------------------------------------------------------------------------

Re: can't use CYGCONF_ARGS with cygport

Yaakov (Cygwin/X) a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> hd wrote:
>   
>> As I understand, CYGCONF_ARGS can provide additionnals parameters to 
>> ./configure
>>
>> if I try :
>>     $ CYGCONF_ARGS='CFLAGS="-g3 -O0"' cygport foo.cygport compile
>>
>> ./configure failed with error message :
>> configure: error: unrecognized option: -O0"
>>
>> It seems that the string CFLAGS="-g3 -O0" is split in 2 parameters 
>> 'CFLAGS="-g3' and '-O0"'
>>
>> I have also tried without success
>>     $ CYGCONF_ARGS='CFLAGS=\"-g3 -O0\"' cygport foo.cygport compile
>>     
>
> Just set CFLAGS in the foo.cygport or in ~/.cygport.conf.
>   
OK, but ~/.cygport.conf alters all .cygport files
Maybe, cygport could also "source" a local ./cygport.conf file in a 
future release ?

Regards

Hiccup with autoreconf vs multiple autoconf installations.

    Hi Yaakov,

  There's a glitch in cygautoreconf().  It calls check_prog_req() to ensure
that autoconf and autoreconf can be found anywhere on $PATH, and it invokes
autoconf without any path to check the version, but it specifies an explicit
path to autoreconf - which might not match the chosen autoconf.  I think it
should let the same PATH search apply to both, like so:

trunk/ChangeLog

	* lib/autotools.cygclass (cygautoreconf):  PATH-search for autoreconf.

branches/cygwin-1.5/ChangeLog

	* bin/cygport.in (cygautoreconf):  PATH-search for autoreconf.

Index: trunk/lib/autotools.cygclass
===================================================================
--- trunk/lib/autotools.cygclass	(revision 5468)
+++ trunk/lib/autotools.cygclass	(working copy)
 <at>  <at>  -167,7 +167,7  <at>  <at>  cygautoreconf() {
 		;;
 	esac

-	/usr/bin/autoreconf --force -i --verbose || error "autoreconf failed"
+	autoreconf --force -i --verbose || error "autoreconf failed"

 	for d in . ${ac_subdirs}
 	do
Index: branches/cygwin-1.5/bin/cygport.in

Re: Hiccup with autoreconf vs multiple autoconf installations.

Dave Korn wrote:
>   There's a glitch in cygautoreconf().  It calls check_prog_req() to ensure
> that autoconf and autoreconf can be found anywhere on $PATH, and it invokes
> autoconf without any path to check the version, but it specifies an explicit
> path to autoreconf - which might not match the chosen autoconf.  I think it
> should let the same PATH search apply to both, like so:

Thanks, committed as r5529 and r5530.

Yaakov
Cygwin Ports

Gnome keeps uninstalling itself

I followed the install instructions to install gnome-terminal. Then I  
did a cygcheck on gnome-terminal and found that one file was missing.  
I redid the install instructions (the missing package came up is  
queued for install). Now when I do cygcheck a bunch of files are  
listed as missing.

The only step I skipped in the reinstall was number 2. Any idea what  
I'm doing wrong?

Thanks,

Peter

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword