Building cygwin1.dll

Building cygwin1.dll

[CM]

I seem to be unable to build the cygwin1.dll from the cygwin sources.
The configuration and compilation go fine, but when make tries to link
the dll, I get errors about undefined symbols:

autoload.o(.wsock32_info+0x0):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.wsock32_info+0xc):autoload.cc: undefined reference to
`wsock_init'
autoload.o(.wsock32_info+0x18):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.wsock32_info+0x30):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.wsock32_info+0x48):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.wsock32_info+0x60):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.wsock32_info+0x78):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.wsock32_info+0x90):autoload.cc: more undefined references to
`std_dll_init' follow
autoload.o(.ws2_32_info+0xc):autoload.cc: undefined reference to
`wsock_init'
autoload.o(.ws2_32_info+0x17):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.ws2_32_info+0x2e):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.ws2_32_info+0x45):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.ws2_32_info+0x5c):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.ws2_32_info+0x73):autoload.cc: undefined reference to
`std_dll_init'
autoload.o(.ws2_32_info+0x8a):autoload.cc: more undefined references to
`std_dll_init' follow
net.o(.text+0x26c6):net.cc: undefined reference to `_wsock32_handle'

I have used nm and grep to look through all the cygwin objects and
libraries and can't seem to find where the symbols are defined. Could
somebody please tell where I am going wrong? To build cygwin, all I did
was, extract the tarball, cd into the directory, make a new directory
inside it called build, cd into that, execute a ../configure, and hit
make. Was there something else I was supposed to do?

Thanks,
CM 




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[rich-paul]

First, a question for the list:  Are problems with building
cygwin on-topic for this list?  I know y'all don't like custom
setups, and custom building may be worse!


I don't know if this is related to your problem, I am currently
checking to see if I can find that routine on my system, but I do
know a couple of things:

	1)	Cygwin rarely seems to build in my environement without
		hacking
		
	2)	Many packages that require an out-of-tree experience to
		build say don't make the build tree under the source
		tree. Generally with these packages (e.g. gcc) I'll cd
		into the unpacked directory, make a dir called 'src',
		move * to src, and then make a dir called bld.  That's
		just my style, the other common way is to use
		/usr/src/xxx and /usr/src/xxx-bld
		
	3)	Many of the problems I have run into have been 'solved'
		by doing a rm -fr of the src tree that is failing.  The
		winsup build builds many things, and I only needed to
		build the actual dll

Let me know if you need more info, I, personally, don't like
using I can't build.  I seem to remember my physics teacher
saying something about 'thinking you can apply a formula you
cannot derive'.  If the feeling is that this is not on-topic for
the list, we'll talk via personal email.

		
On Sun, May 26, 2002 at 01:50:35PM +0100, CM wrote:
> I seem to be unable to build the cygwin1.dll from the cygwin sources.
> The configuration and compilation go fine, but when make tries to link
> the dll, I get errors about undefined symbols:
> 
> autoload.o(.wsock32_info+0x0):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.wsock32_info+0xc):autoload.cc: undefined reference to
> `wsock_init'
> autoload.o(.wsock32_info+0x18):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.wsock32_info+0x30):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.wsock32_info+0x48):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.wsock32_info+0x60):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.wsock32_info+0x78):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.wsock32_info+0x90):autoload.cc: more undefined references to
> `std_dll_init' follow
> autoload.o(.ws2_32_info+0xc):autoload.cc: undefined reference to
> `wsock_init'
> autoload.o(.ws2_32_info+0x17):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.ws2_32_info+0x2e):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.ws2_32_info+0x45):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.ws2_32_info+0x5c):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.ws2_32_info+0x73):autoload.cc: undefined reference to
> `std_dll_init'
> autoload.o(.ws2_32_info+0x8a):autoload.cc: more undefined references to
> `std_dll_init' follow
> net.o(.text+0x26c6):net.cc: undefined reference to `_wsock32_handle'
> 
> I have used nm and grep to look through all the cygwin objects and
> libraries and can't seem to find where the symbols are defined. Could
> somebody please tell where I am going wrong? To build cygwin, all I did
> was, extract the tarball, cd into the directory, make a new directory
> inside it called build, cd into that, execute a ../configure, and hit
> make. Was there something else I was supposed to do?
> 
> Thanks,
> CM 
> 
> 
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Larry Hall (RFK Partners, Inc)]

At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
>First, a question for the list:  Are problems with building
>cygwin on-topic for this list?  I know y'all don't like custom
>setups, and custom building may be worse!


I'm not sure what "custom building" means but issues with building 
the Cygwin DLL are on-topic for this list.  Generally speaking though,
the process should be as described in the FAQ entry:


How do I rebuild the tools on my NT box?
http://cygwin.com/faq/faq_4.html#SEC102



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Christopher Faylor]

On Tue, May 28, 2002 at 12:28:04PM -0400, Larry Hall (RFK Partners, Inc) wrote:
>At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
>>First, a question for the list: Are problems with building cygwin
>>on-topic for this list?  I know y'all don't like custom setups, and
>>custom building may be worse!
>
>I'm not sure what "custom building" means but issues with building the
>Cygwin DLL are on-topic for this list.  Generally speaking though, the
>process should be as described in the FAQ entry:
>
>How do I rebuild the tools on my NT box?
>http://cygwin.com/faq/faq_4.html#SEC102

Yeah, but I have a lot of problems with those instructions.  I've found
that I generally have to convert all of the C code to Modula 3 and
rewrite the Makefiles as c-shell scripts before I can rebuild anything.
Sometimes I have to hand-compile stuff, too.  That's pretty tedious.

Of course, maybe this is just my own personal preferences showing
through.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Larry Hall (RFK Partners, Inc)]

At 01:12 PM 5/28/2002, Christopher Faylor wrote:
>On Tue, May 28, 2002 at 12:28:04PM -0400, Larry Hall (RFK Partners, Inc) wrote:
> >At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
> >>First, a question for the list: Are problems with building cygwin
> >>on-topic for this list?  I know y'all don't like custom setups, and
> >>custom building may be worse!
> >
> >I'm not sure what "custom building" means but issues with building the
> >Cygwin DLL are on-topic for this list.  Generally speaking though, the
> >process should be as described in the FAQ entry:
> >
> >How do I rebuild the tools on my NT box?
> >http://cygwin.com/faq/faq_4.html#SEC102
>
>Yeah, but I have a lot of problems with those instructions.  I've found
>that I generally have to convert all of the C code to Modula 3 and
>rewrite the Makefiles as c-shell scripts before I can rebuild anything.
>Sometimes I have to hand-compile stuff, too.  That's pretty tedious.


<humor>
I'd direct you to the email list archives but you'd probably be overwhelmed
by the number of posts with people saying they do the same thing.  Of course
when you run into this kind of problem, the best thing to do is send email
to this list about it and repeat it many times.  Most of the folks on this
list that could help you have allot of free time so they prefer to read 
multiple repeat posts.  However, sometimes the best course of action when 
you encounter a problem like this is to drop back to version B14 of Cygwin.
Either that or just use DOS or CPM.  These often work much better than the
current version of Cygwin.  But since you're a newbie, Chris, we can't 
expect you to know that.
</humor>





Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Christopher Faylor]

On Tue, May 28, 2002 at 01:49:38PM -0400, Larry Hall (RFK Partners, Inc) wrote:
>At 01:12 PM 5/28/2002, Christopher Faylor wrote:
>>On Tue, May 28, 2002 at 12:28:04PM -0400, Larry Hall (RFK Partners, Inc) wrote:
>> >At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
>> >>First, a question for the list: Are problems with building cygwin
>> >>on-topic for this list?  I know y'all don't like custom setups, and
>> >>custom building may be worse!
>> >
>> >I'm not sure what "custom building" means but issues with building the
>> >Cygwin DLL are on-topic for this list.  Generally speaking though, the
>> >process should be as described in the FAQ entry:
>> >
>> >How do I rebuild the tools on my NT box?
>> >http://cygwin.com/faq/faq_4.html#SEC102
>>
>>Yeah, but I have a lot of problems with those instructions.  I've found
>>that I generally have to convert all of the C code to Modula 3 and
>>rewrite the Makefiles as c-shell scripts before I can rebuild anything.
>>Sometimes I have to hand-compile stuff, too.  That's pretty tedious.
>
>
><humor>
>I'd direct you to the email list archives but you'd probably be overwhelmed
>by the number of posts with people saying they do the same thing.  Of course
>when you run into this kind of problem, the best thing to do is send email
>to this list about it and repeat it many times.  Most of the folks on this
>list that could help you have allot of free time so they prefer to read 
>multiple repeat posts.  However, sometimes the best course of action when 
>you encounter a problem like this is to drop back to version B14 of Cygwin.
>Either that or just use DOS or CPM.  These often work much better than the
>current version of Cygwin.  But since you're a newbie, Chris, we can't 
>expect you to know that.
></humor>

UNSUBSCRIBE

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Larry Hall (RFK Partners, Inc)]

At 01:57 PM 5/28/2002, Christopher Faylor wrote:
>On Tue, May 28, 2002 at 01:49:38PM -0400, Larry Hall (RFK Partners, Inc) wrote:
> >At 01:12 PM 5/28/2002, Christopher Faylor wrote:
> >>On Tue, May 28, 2002 at 12:28:04PM -0400, Larry Hall (RFK Partners, Inc) wrote:
> >> >At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
> >> >>First, a question for the list: Are problems with building cygwin
> >> >>on-topic for this list?  I know y'all don't like custom setups, and
> >> >>custom building may be worse!
> >> >
> >> >I'm not sure what "custom building" means but issues with building the
> >> >Cygwin DLL are on-topic for this list.  Generally speaking though, the
> >> >process should be as described in the FAQ entry:
> >> >
> >> >How do I rebuild the tools on my NT box?
> >> >http://cygwin.com/faq/faq_4.html#SEC102
> >>
> >>Yeah, but I have a lot of problems with those instructions.  I've found
> >>that I generally have to convert all of the C code to Modula 3 and
> >>rewrite the Makefiles as c-shell scripts before I can rebuild anything.
> >>Sometimes I have to hand-compile stuff, too.  That's pretty tedious.
> >
> >
> ><humor>
> >I'd direct you to the email list archives but you'd probably be overwhelmed
> >by the number of posts with people saying they do the same thing.  Of course
> >when you run into this kind of problem, the best thing to do is send email
> >to this list about it and repeat it many times.  Most of the folks on this
> >list that could help you have allot of free time so they prefer to read 
> >multiple repeat posts.  However, sometimes the best course of action when 
> >you encounter a problem like this is to drop back to version B14 of Cygwin.
> >Either that or just use DOS or CPM.  These often work much better than the
> >current version of Cygwin.  But since you're a newbie, Chris, we can't 
> >expect you to know that.
> ></humor>
>
>UNSUBSCRIBE



LOL!

Sometimes, less is really more! :-)



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[rich-paul]

Real programmers use cat > a.out.  xxd is for wimps.

On Tue, May 28, 2002 at 01:12:41PM -0400, Christopher Faylor wrote:
> On Tue, May 28, 2002 at 12:28:04PM -0400, Larry Hall (RFK Partners, Inc) wrote:
> >At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
> >>First, a question for the list: Are problems with building cygwin
> >>on-topic for this list?  I know y'all don't like custom setups, and
> >>custom building may be worse!
> >
> >I'm not sure what "custom building" means but issues with building the
> >Cygwin DLL are on-topic for this list.  Generally speaking though, the
> >process should be as described in the FAQ entry:
> >
> >How do I rebuild the tools on my NT box?
> >http://cygwin.com/faq/faq_4.html#SEC102
> 
> Yeah, but I have a lot of problems with those instructions.  I've found
> that I generally have to convert all of the C code to Modula 3 and
> rewrite the Makefiles as c-shell scripts before I can rebuild anything.
> Sometimes I have to hand-compile stuff, too.  That's pretty tedious.
> 
> Of course, maybe this is just my own personal preferences showing
> through.
> 
> cgf
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[rich-paul]

I meant that what I have built, I did not install through
setup.exe ...

The faq entry is good as far as it goes, but generally there are
problems. With my current download I believe they involved a
present but empty directory (perhaps windows32api?), and a couple
of other things.  I just removed the subtrees that didn't built,
and was able to patch and build what I needed.


On Tue, May 28, 2002 at 12:28:04PM -0400, Larry Hall (RFK Partners, Inc) wrote:
> At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
> >First, a question for the list:  Are problems with building
> >cygwin on-topic for this list?  I know y'all don't like custom
> >setups, and custom building may be worse!
> 
> 
> I'm not sure what "custom building" means but issues with building 
> the Cygwin DLL are on-topic for this list.  Generally speaking though,
> the process should be as described in the FAQ entry:
> 
> 
> How do I rebuild the tools on my NT box?
> http://cygwin.com/faq/faq_4.html#SEC102
> 
> 
> 
> Larry Hall                              lhall@rfk.com
> RFK Partners, Inc.                      http://www.rfk.com
> 838 Washington Street                   (508) 893-9779 - RFK Office
> Holliston, MA 01746                     (508) 893-9889 - FAX
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Christopher Faylor]

On Tue, May 28, 2002 at 07:02:38PM -0400, rich-paul@rich-paul.net wrote:
>I meant that what I have built, I did not install through
>setup.exe ...
>
>The faq entry is good as far as it goes, but generally there are
>problems. With my current download I believe they involved a
>present but empty directory (perhaps windows32api?), and a couple
>of other things.  I just removed the subtrees that didn't built,
>and was able to patch and build what I needed.

I'll remove the empty subdirectories from future source tar balls.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Larry Hall (RFK Partners, Inc)]

At 07:02 PM 5/28/2002, rich-paul@rich-paul.net wrote:
>I meant that what I have built, I did not install through
>setup.exe ...


Ah-ha!  You're the one!  We can't allow this subversion!  You will be 
forever banished!! ;-)

I'd hope that anyone who's capable enough to build Cygwin from source 
would also be capable enough to handle basic configuration issues that
setup helps to automate.  I think people can use their best judgement 
about asking questions in this regard.  But I'd be surprised to see 
any thoughtful question about building Cygwin shot-down based on the 
premise that it's off-topic because setup hasn't been used.  I think 
the person involved here has a different goal than those who are just
looking to install Cygwin.  This list can accommodate both of these 
"types" IMO.


>The faq entry is good as far as it goes, but generally there are
>problems. With my current download I believe they involved a
>present but empty directory (perhaps windows32api?), and a couple
>of other things.  I just removed the subtrees that didn't built,
>and was able to patch and build what I needed.
>
>
>On Tue, May 28, 2002 at 12:28:04PM -0400, Larry Hall (RFK Partners, Inc) wrote:
> > At 12:03 PM 5/28/2002, rich-paul@rich-paul.net wrote:
> > >First, a question for the list:  Are problems with building
> > >cygwin on-topic for this list?  I know y'all don't like custom
> > >setups, and custom building may be worse!
> > 
> > 
> > I'm not sure what "custom building" means but issues with building 
> > the Cygwin DLL are on-topic for this list.  Generally speaking though,
> > the process should be as described in the FAQ entry:
> > 
> > 
> > How do I rebuild the tools on my NT box?
> > http://cygwin.com/faq/faq_4.html#SEC102
> > 
> > 
> > 
> > Larry Hall                              lhall@rfk.com
> > RFK Partners, Inc.                      http://www.rfk.com
> > 838 Washington Street                   (508) 893-9779 - RFK Office
> > Holliston, MA 01746                     (508) 893-9889 - FAX
> > 
> > 
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting:         http://cygwin.com/bugs.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> > 
>
>-- 
>Got freedom?  Vote Libertarian:  http://www.lp.org
>
>--
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting:         http://cygwin.com/bugs.html
>Documentation:         http://cygwin.com/docs.html
>FAQ:                   http://cygwin.com/faq/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[rich-paul]

Thanks!

I'm finding some more problems, but haven't had time to really
document them.  I'm leaving the notes which I started taking in
this editor here, in case anyone's interested, but don't flame me
for giving you raw ramblings, and letting you sort it out ...
I'll clean 'em up and submit 'em as a patch when I get a chance.
They're just there if anyone wants to read 'em.

Anyway, I'll let you know if/when I get through it, I've had this
editor open forever.  I'll try to get you enough patch that the
next version can compile 'out of the box'.  <G>

<ramble mode on>
	I noticed that removing that directory exposes another problem,
	the makefile wants to make a target called w32api, but there are
	no rules for such a target.  Of course, make hapilly thought
	it had already made it, in the form of a directory, so didn't
	complain.

	I removed the dependencies from four lines, and am trying again
	...

	Hmmm ... switching the lib directories to use the installed
	mingw32/win32api

	OK, got farther, added a check for the cross-directory
	libkernel32.a dependency ....

	At this point, started dying of 'parse error before symbol
	__gnuc_va_list' in stdio.h.  It does include stdarg.h, but
	perhaps whatever keeps stdio.h from exposing va_list, as the
	comment in the gnuc stdio says, is the culpret.  Anyway, I didn't
	want to dig too deeply, so I played with making .i files  for
	a while, and resorted to commenting out the conditionals at
	line 143, so that __VALIST would be #defined to char*.

	That may come back to haunt me when I try to compile some
	c++, but I'm not sure ... can't recall is varargs fns require
	c linkage or not.

	Well, c linkage aside, it haunted me ... 'new' c++ void*
	casting rules.  Oh, well, let's try void* instead.  <ramble
	mode off>




On Tue, May 28, 2002 at 07:29:30PM -0400, Christopher Faylor
wrote:
> On Tue, May 28, 2002 at 07:02:38PM -0400,
> rich-paul@rich-paul.net wrote:
> >I meant that what I have built, I did not install through
> >setup.exe ...
> >
> >The faq entry is good as far as it goes, but generally there
> >are problems. With my current download I believe they involved
> >a present but empty directory (perhaps windows32api?), and a
> >couple of other things.  I just removed the subtrees that
> >didn't built, and was able to patch and build what I needed.
> 
> I'll remove the empty subdirectories from future source tar
> balls.
> 
> cgf
> 
> -- Unsubscribe info:
> http://cygwin.com/ml/#unsubscribe-simple Bug reporting:
> http://cygwin.com/bugs.html Documentation:
> http://cygwin.com/docs.html FAQ:
> http://cygwin.com/faq/
> 

-- Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Christopher Faylor]

On Wed, May 29, 2002 at 09:17:28AM -0400, rich-paul@rich-paul.net wrote:
>	I noticed that removing that directory exposes another problem,
>	the makefile wants to make a target called w32api, but there are
>	no rules for such a target.  Of course, make hapilly thought
>	it had already made it, in the form of a directory, so didn't
>	complain.

That's because you *need* the directory to be populated.

>	I removed the dependencies from four lines, and am trying again
>	...

Wrong "solution".

>	Hmmm ... switching the lib directories to use the installed
>	mingw32/win32api

Wrong "solution".

>	OK, got farther, added a check for the cross-directory
>	libkernel32.a dependency ....
>
>	At this point, started dying of 'parse error before symbol
>	__gnuc_va_list' in stdio.h.  It does include stdarg.h, but
>	perhaps whatever keeps stdio.h from exposing va_list, as the
>	comment in the gnuc stdio says, is the culpret.  Anyway, I didn't
>	want to dig too deeply, so I played with making .i files  for
>	a while, and resorted to commenting out the conditionals at
>	line 143, so that __VALIST would be #defined to char*.

Something is wrong in your installation.

When, you think about this problem, think about it from the point of
view that many people (me, for instance) are building cygwin.  We don't
build it by hacking at the Makefile.  We build it by having the complete
sources installed.

If you have to start editing things, you're obviously going down the
wrong track.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[rich-paul]

OK, why don't I start over:

	My assumption, from the previous discussion, was that the directions
	in the FAQ were, in theory, sufficient to actually perform the task.
	Therefore, I assumed that cygwin-1.3.10-1-src.tar.bz2 was supposed
	to be able to build alone, and that it's inability to do so was
	brokenness on it's part, which has been hidden because it's
	generally only compiled as part of the larger 'net-release',
	which contains other things.

	This was bolstered by being able to compile a working cygwin1.dll
	using, I assume, my installed version of w32api in place of the one
	that belongs in the source tree.  It may be, however, that doing
	this worked "by accident" and should not be assumed to be a workable
	thing in the future.

	But if there are other packages that *SHOULD* be required to build
	cygwin1.dll, then my assumption was invalid.  My next instict was to
	say "OK, the brokenness is in the FAQ".  But having re-read that
	entry, I cannot say that it's technically wrong.  It merely says to
	put "the sources" into /src.  It does not say what constitutes "The
	sources".  It was *my* assumption that the only sources required to
	build cygwin1.dll were contained in cygwin-1.3.10-1-src.tar.bz2.

	So now the question becomes, what is the minimum subset of the
	source distribution that must be unpacked into /src in order for
	following the directions in the FAQ to work, and how should they be
	put there.  I assume that the three empty directories, w32api, mingw,
	and cinstall should be filled, so I'll start with them and see if
	that produces a dll.

	Another question:  Are there any directions as to how to use the
	mknetrel package from the cygwin-apps cvs tree?  I've read some of
	the script, and it looks like it might make life easier, but it
	appears to need things mounted in particular absolute directories.
	If there are no such docs, would you be interested in having some?

On Wed, May 29, 2002 at 10:36:18AM -0400, Christopher Faylor wrote:
> On Wed, May 29, 2002 at 09:17:28AM -0400, rich-paul@rich-paul.net wrote:
> >	I noticed that removing that directory exposes another problem,
> >	the makefile wants to make a target called w32api, but there are
> >	no rules for such a target.  Of course, make hapilly thought
> >	it had already made it, in the form of a directory, so didn't
> >	complain.
> 
> That's because you *need* the directory to be populated.
> 
> >	I removed the dependencies from four lines, and am trying again
> >	...
> 
> Wrong "solution".
> 
> >	Hmmm ... switching the lib directories to use the installed
> >	mingw32/win32api
> 
> Wrong "solution".
> 
> >	OK, got farther, added a check for the cross-directory
> >	libkernel32.a dependency ....
> >
> >	At this point, started dying of 'parse error before symbol
> >	__gnuc_va_list' in stdio.h.  It does include stdarg.h, but
> >	perhaps whatever keeps stdio.h from exposing va_list, as the
> >	comment in the gnuc stdio says, is the culpret.  Anyway, I didn't
> >	want to dig too deeply, so I played with making .i files  for
> >	a while, and resorted to commenting out the conditionals at
> >	line 143, so that __VALIST would be #defined to char*.
> 
> Something is wrong in your installation.
> 
> When, you think about this problem, think about it from the point of
> view that many people (me, for instance) are building cygwin.  We don't
> build it by hacking at the Makefile.  We build it by having the complete
> sources installed.
> 
> If you have to start editing things, you're obviously going down the
> wrong track.
> 
> cgf
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[..]

rich-paul@rich-paul.net wrote:
> 
> OK, why don't I start over:
> 
>         My assumption, from the previous discussion, was that the directions
>         in the FAQ were, in theory, sufficient to actually perform the task.

Not yet. I myself whish that this was more refined, but it might
take a while for those that by their concentrated experiance consider
points to be trivial to understand to the extent to which documentation
is required to adapt that experiance to your or another's needs.


-- 
--=<> Dr. Clue (A.K.A. Ian A. Storms) <>=--
--=<[]>=- http://www.drclue.net
--=<[]>=- C++ HTML JavaScript DHTML CGI TCP/IP SQL JAVA VRML NSAPI 
--=<[]>=- http://www.drclue.net/F1.cgi/HTML/HTML.html	(My famous
HTML/CGI guide.)
--=<[]>=- http://www.drclue.net/beta			(My X-BROWSER DHTML library.)



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[Christopher Faylor]

On Sun, Jun 02, 2002 at 12:47:47AM -0400, rich-paul@rich-paul.net wrote:
>Another question: Are there any directions as to how to use the
>mknetrel package from the cygwin-apps cvs tree?  I've read some of the
>script, and it looks like it might make life easier, but it appears to
>need things mounted in particular absolute directories.  If there are
>no such docs, would you be interested in having some?

I never say no to documentation.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll

[rich-paul]

Great, can anyone here provide any tips as to starting points in using
the mknetrel package?  I'll reverse engineer it if need be or to fill in
the blanks, but I'm guessing somebody knows something.  <G>

What I know so far, is before you start using mknetrel, you've gotta
install getopt.

C'mon, lay it on me, I promise they won't make you sleep with the
fishes.

On Sun, Jun 02, 2002 at 02:28:24AM -0400, Christopher Faylor wrote:
> On Sun, Jun 02, 2002 at 12:47:47AM -0400, rich-paul@rich-paul.net wrote:
> >Another question: Are there any directions as to how to use the
> >mknetrel package from the cygwin-apps cvs tree?  I've read some of the
> >script, and it looks like it might make life easier, but it appears to
> >need things mounted in particular absolute directories.  If there are
> >no such docs, would you be interested in having some?
> 
> I never say no to documentation.
> 
> cgf
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Building cygwin1.dll and mknetrel

[linguist-cygwin]

Here are some observations of building cygwin1.dll with the mknetrel
package.  I have not yet looked enough at the innards to be able to
document how to add an 'extras' file, which is how mknetrel overrides
the normal build procedure for some packages.  All in all, it looks like
a pretty elegant package made up mostly of shell scripts, which
themselves are made up mostly of shell functions.  It may be copied into
the FAQ or anywhere else you may like.  There's even a company in Oragon
that will print in onto a roll of toilet paper for you. ;->  If it
doesn't end up on the official web, I'll probably just throw it on my
site.


For testing of this script, I made a fresh install with setup, and
installed the following packages:

ash            bash           binutils       bzip2          crypt          
cvs            cygwin         diffutils      ed             fileutils      
findutils      gawk           gcc            gdbm           grep           
gzip           libbz2_1       libintl1       libncurses5    libncurses6    
libpng         libreadline4   libreadline5   make           mingw-runtime  
pcre          *perl           sed            sh-utils       tar            
terminfo      *tetex-beta     texinfo        textutils     *getopt 

This appears to be close to the minimum set.  Perl may not be needed.
tetex-beta really isn't needed, it is installed just for readlink.  The
command, I think, could be replaced with:

| #!/usr/bin/perl
| $x = readlink $ARGV[0];
| exit 1 unless defined $x;
| print $x, "\n";
| exit 0;

or maybe
|#!/bin/bash
|find "$1" -type l -maxdepth 0 -printf '%l\n'


getopt is not a cygwin package.  My copy came out of a copy of smail on
my linux box, it's PD from AT&T, and compiled out of the box on cygwin.
It could probably be replaced with a shell script/function.

After installing the system, and adding getopt, the following script was
sufficient to build cygwin; it ended up in a lovely tarball in
/netrel/uploads.

|PATH=/netrel/mknetrel/bin:/bin
|cd /bin
|for name in c++ ar ranlib g++ dlltool as windres nm strip; do
|  do ln -s $name i686-pc-cygwin-$name
|done
|cd /
|mkdir netrel
|cd netrel
|cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/cygwin-apps co
|mknetrel
|mkdir src inst build uploads extra
|cd src
|
|tar -xjf $SETUPDIR/release/cygwin/*-src.tar.bz2
|tar -xjf $SETUPDIR/release/mingw-runtime/*-src.tar.bz2
|tar -xjf $SETUPDIR/release/w32api/*-src.tar.bz2
|
|cd cygwin*/winsup
|rm -fr mingw cinstall w32api
|ln -s /netrel/src/mingw-runtime-*/ mingw
|ln -s /netrel/src/w32api-*/ w32api
|
|cd /netrel
|mknetrel cygwin 2>&1 | tee mknetrel.cygwin.out

Notes:
	*	The first time you connect to the CVS server, you're going to
	 	have to do a cvs login
		
	*	mknetrel has hardcoded absolute paths.  your build tree must be
	 	in /netrel exactly.

	*	mknetrel, it appears, can build most but not all cygwin
	 	packages.  vim, for example, looses, because the build must be
		done in the src directory.  It looks like an 'extras' script
		could be produced to accomidate vim, either with a link tree (I
		seem to recall the vim build supports this) or some other hack.

	*	On my production system, I had to change the '#!/bin/sh' to
		'#!/bin/bash' on one of the mknetrel shell scripts
		to get the shell to accept the usage of getopts ... but on the
		fresh install, I did not.  (This is the bash getopts builtin,
		not the standalone and singular 'getopt' discussed above)
		
	*	The fact that mknetrel uses i686-pc-cygwin-xxx as it's tools
		during the build implies that it may work with a cross compiler
		as well, or may have been developed to cross compile.  I haven't
		yet had time to prove this.

	*	I use wildcards in some places to avoid explicitly stating
		package versions.  The drawback to this approach is that it will
		break in the presence of dup package versions.

	*	Some of my test builds produced a linux version of libiberty as
		an added bonus.  I don't know why, but it didn't seem to hurt
		anything

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[rich-paul]

Well, I don't want to give the list a flow of conciousness on this
thing, but I will note that you can avoid the linux packages my setting
up a ~/.mknetrel file as a shell script that defines build_config_opts.
By default, it explicitly sets the build system to be a linux box.

Also, you can set a series of variables like build_cxx, build_cc,
build_ranlib, etc rather than creating the i686-cygwin symbolic links.

And lastly, I was wrong about /netrel, it is a default, not hardcoded.

Anyway, some of this was added within the last few days.

On Mon, Jun 03, 2002 at 05:33:25AM -0400, linguist-cygwin@rich-paul.net wrote:
> Here are some observations of building cygwin1.dll with the mknetrel
> package.  I have not yet looked enough at the innards to be able to
> document how to add an 'extras' file, which is how mknetrel overrides
> the normal build procedure for some packages.  All in all, it looks like
> a pretty elegant package made up mostly of shell scripts, which
> themselves are made up mostly of shell functions.  It may be copied into
> the FAQ or anywhere else you may like.  There's even a company in Oragon
> that will print in onto a roll of toilet paper for you. ;->  If it
> doesn't end up on the official web, I'll probably just throw it on my
> site.
> 
> 
> For testing of this script, I made a fresh install with setup, and
> installed the following packages:
> 
> ash            bash           binutils       bzip2          crypt          
> cvs            cygwin         diffutils      ed             fileutils      
> findutils      gawk           gcc            gdbm           grep           
> gzip           libbz2_1       libintl1       libncurses5    libncurses6    
> libpng         libreadline4   libreadline5   make           mingw-runtime  
> pcre          *perl           sed            sh-utils       tar            
> terminfo      *tetex-beta     texinfo        textutils     *getopt 
> 
> This appears to be close to the minimum set.  Perl may not be needed.
> tetex-beta really isn't needed, it is installed just for readlink.  The
> command, I think, could be replaced with:
> 
> | #!/usr/bin/perl
> | $x = readlink $ARGV[0];
> | exit 1 unless defined $x;
> | print $x, "\n";
> | exit 0;
> 
> or maybe
> |#!/bin/bash
> |find "$1" -type l -maxdepth 0 -printf '%l\n'
> 
> 
> getopt is not a cygwin package.  My copy came out of a copy of smail on
> my linux box, it's PD from AT&T, and compiled out of the box on cygwin.
> It could probably be replaced with a shell script/function.
> 
> After installing the system, and adding getopt, the following script was
> sufficient to build cygwin; it ended up in a lovely tarball in
> /netrel/uploads.
> 
> |PATH=/netrel/mknetrel/bin:/bin
> |cd /bin
> |for name in c++ ar ranlib g++ dlltool as windres nm strip; do
> |  do ln -s $name i686-pc-cygwin-$name
> |done
> |cd /
> |mkdir netrel
> |cd netrel
> |cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/cygwin-apps co
> |mknetrel
> |mkdir src inst build uploads extra
> |cd src
> |
> |tar -xjf $SETUPDIR/release/cygwin/*-src.tar.bz2
> |tar -xjf $SETUPDIR/release/mingw-runtime/*-src.tar.bz2
> |tar -xjf $SETUPDIR/release/w32api/*-src.tar.bz2
> |
> |cd cygwin*/winsup
> |rm -fr mingw cinstall w32api
> |ln -s /netrel/src/mingw-runtime-*/ mingw
> |ln -s /netrel/src/w32api-*/ w32api
> |
> |cd /netrel
> |mknetrel cygwin 2>&1 | tee mknetrel.cygwin.out
> 
> Notes:
> 	*	The first time you connect to the CVS server, you're going to
> 	 	have to do a cvs login
> 		
> 	*	mknetrel has hardcoded absolute paths.  your build tree must be
> 	 	in /netrel exactly.
> 
> 	*	mknetrel, it appears, can build most but not all cygwin
> 	 	packages.  vim, for example, looses, because the build must be
> 		done in the src directory.  It looks like an 'extras' script
> 		could be produced to accomidate vim, either with a link tree (I
> 		seem to recall the vim build supports this) or some other hack.
> 
> 	*	On my production system, I had to change the '#!/bin/sh' to
> 		'#!/bin/bash' on one of the mknetrel shell scripts
> 		to get the shell to accept the usage of getopts ... but on the
> 		fresh install, I did not.  (This is the bash getopts builtin,
> 		not the standalone and singular 'getopt' discussed above)
> 		
> 	*	The fact that mknetrel uses i686-pc-cygwin-xxx as it's tools
> 		during the build implies that it may work with a cross compiler
> 		as well, or may have been developed to cross compile.  I haven't
> 		yet had time to prove this.
> 
> 	*	I use wildcards in some places to avoid explicitly stating
> 		package versions.  The drawback to this approach is that it will
> 		break in the presence of dup package versions.
> 
> 	*	Some of my test builds produced a linux version of libiberty as
> 		an added bonus.  I don't know why, but it didn't seem to hurt
> 		anything
> 
> -- 
> Got freedom?  Vote Libertarian:  http://www.lp.org
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[egor duda]

Hi!

Monday, 03 June, 2002 rich-paul@rich-paul.net rich-paul@rich-paul.net wrote:

rprpn> Well, I don't want to give the list a flow of conciousness on this
rprpn> thing, but I will note that you can avoid the linux packages my setting
rprpn> up a ~/.mknetrel file as a shell script that defines build_config_opts.
rprpn> By default, it explicitly sets the build system to be a linux box.

rprpn> Also, you can set a series of variables like build_cxx, build_cc,
rprpn> build_ranlib, etc rather than creating the i686-cygwin symbolic links.

rprpn> And lastly, I was wrong about /netrel, it is a default, not hardcoded.

rprpn> Anyway, some of this was added within the last few days.

exactly. see thread
http://sources.redhat.com/ml/cygwin-apps/2002-05/msg00313.html

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[Christopher Faylor]

On Mon, Jun 03, 2002 at 05:33:25AM -0400, linguist-cygwin@rich-paul.net wrote:
>	*	mknetrel, it appears, can build most but not all cygwin
>	 	packages.  vim, for example, looses, because the build must be
>		done in the src directory.  It looks like an 'extras' script
>		could be produced to accomidate vim, either with a link tree (I
>		seem to recall the vim build supports this) or some other hack.

mknetrel is, AFAIK, only used by myself for producing net release packages.  Egor
Duda has obviously been experimenting with it (possibly for use in building gcc)
but he doesn't use it for package maintenance yet, AFAIK.

>	*	On my production system, I had to change the '#!/bin/sh' to
>		'#!/bin/bash' on one of the mknetrel shell scripts
>		to get the shell to accept the usage of getopts ... but on the
>		fresh install, I did not.  (This is the bash getopts builtin,
>		not the standalone and singular 'getopt' discussed above)

Yes, I have never run this under cygwin, actually.  It was intended as a
cross-compilation environment.  I'm surprised that it works on cygwin
with so few changes.

>	*	The fact that mknetrel uses i686-pc-cygwin-xxx as it's tools
>		during the build implies that it may work with a cross compiler
>		as well, or may have been developed to cross compile.  I haven't
>		yet had time to prove this.

Yep.

>	*	I use wildcards in some places to avoid explicitly stating
>		package versions.  The drawback to this approach is that it will
>		break in the presence of dup package versions.

You should be able to say "mknetrel cygwin" to have it build the latest version.
Again, I'm surprised that it would actually work with explicit versions.

>	*	Some of my test builds produced a linux version of libiberty as
>		an added bonus.  I don't know why, but it didn't seem to hurt
>		anything

"That's the way it works" (tm)

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[egor duda]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Hi!

Tuesday, 04 June, 2002 Christopher Faylor cgf@redhat.com wrote:

>>       *       On my production system, I had to change the '#!/bin/sh' to
>>               '#!/bin/bash' on one of the mknetrel shell scripts
>>               to get the shell to accept the usage of getopts ... but on the
>>               fresh install, I did not.  (This is the bash getopts builtin,
>>               not the standalone and singular 'getopt' discussed above)

CF> Yes, I have never run this under cygwin, actually.  It was intended as a
CF> cross-compilation environment.  I'm surprised that it works on cygwin
CF> with so few changes.

I'm running it on cygwin. All i need is to build getopt.exe and
readlink.exe from two attached source files. readlink.c is taken from
OpenBSD cvs, and getopt.c is slightly patched version of getopt.c from
linux-utils. They both can be built out-of-the-box.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

[-- Attachment #2: readlink.c --]
[-- Type: application/octet-stream, Size: 2511 bytes --]

/*
 * $OpenBSD: readlink.c,v 1.18 1998/08/24 14:45:33 kstailey Exp $
 *
 * Copyright (c) 1997
 *	Kenneth Stailey (hereinafter referred to as the author)
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 *    derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
 * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#include <limits.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int
main(argc, argv)
	int argc;
	char **argv;
{
	char buf[PATH_MAX];
	int n, ch, nflag = 0, fflag = 0;
	extern int optind;

	while ((ch = getopt(argc, argv, "fn")) != -1)
		switch (ch) {
		case 'f':
			fflag = 1;
			break;
		case 'n':
			nflag = 1;
			break;
		default:
			(void)fprintf(stderr,
			    "usage: readlink [-n] [-f] symlink\n");
			exit(1);
		}
	argc -= optind;
	argv += optind;

	if (argc != 1) {
		fprintf(stderr, "usage: readlink [-n] [-f] symlink\n");
		exit(1);
	}

	n = strlen(argv[0]);
	if (n > PATH_MAX - 1) {
		fprintf(stderr,
			"readlink: filename longer than PATH_MAX-1 (%d)\n",
			PATH_MAX - 1);
		exit(1);
	}

	if (fflag)
		realpath(argv[0], buf);
	else {
		if ((n = readlink(argv[0], buf, sizeof buf-1)) < 0)
			exit(1);
		buf[n] = '\0';
	}

	printf("%s", buf);
	if (!nflag)
		putchar('\n');
	exit(0);
}

[-- Attachment #3: getopt.c --]
[-- Type: application/octet-stream, Size: 13278 bytes --]

/*
    getopt.c - Enhanced implementation of BSD getopt(1)
    Copyright (c) 1997, 1998, 1999, 2000  Frodo Looijaard <frodol@dds.nl>

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/

/* 
 * Version 1.0-b4: Tue Sep 23 1997. First public release.
 * Version 1.0: Wed Nov 19 1997. 
 *   Bumped up the version number to 1.0
 *   Fixed minor typo (CSH instead of TCSH)
 * Version 1.0.1: Tue Jun 3 1998
 *   Fixed sizeof instead of strlen bug
 *   Bumped up the version number to 1.0.1
 * Version 1.0.2: Thu Jun 11 1998 (not present)
 *   Fixed gcc-2.8.1 warnings
 *   Fixed --version/-V option (not present)
 * Version 1.0.5: Tue Jun 22 1999
 *   Make -u option work (not present)
 * Version 1.0.6: Tue Jun 27 2000
 *   No important changes
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <ctype.h>

#if LIBCGETOPT
#include <getopt.h>
#else
#include "getopt.h"
#endif

#define _(x) x

/* NON_OPT is the code that is returned when a non-option is found in '+' 
   mode */
#define NON_OPT 1
/* LONG_OPT is the code that is returned when a long option is found. */
#define LONG_OPT 2

/* The shells recognized. */
typedef enum {BASH,TCSH} shell_t;


/* Some global variables that tells us how to parse. */
shell_t shell=BASH; /* The shell we generate output for. */
int quiet_errors=0; /* 0 is not quiet. */
int quiet_output=0; /* 0 is not quiet. */
int quote=1; /* 1 is do quote. */
#ifdef HAVE_GETOPT_LONG_ONLY
int alternative=0; /* 0 is getopt_long, 1 is getopt_long_only */
#endif

/* Function prototypes */
void *our_malloc(size_t size);
void *our_realloc(void *ptr, size_t size);
const char *normalize(const char *arg);
int generate_output(char * argv[],int argc,const char *optstr,
                    const struct option *longopts);
int main(int argc, char *argv[]);
void parse_error(const char *message);
void add_long_options(char *options);
void add_longopt(const char *name,int has_arg);
void print_help(void);
void set_shell(const char *new_shell);
void set_initial_shell(void);

void *our_malloc(size_t size)
{
	void *ret=malloc(size);
	if (! ret) {
		fprintf(stderr,_("%s: Out of memory!\n"),"getopt");
		exit(3);
	}
	return(ret);
}

void *our_realloc(void *ptr, size_t size)
{
	void *ret=realloc(ptr,size);
	if (! ret && size) {
		fprintf(stderr,_("%s: Out of memory!\n"),"getopt");
		exit(3);
	}
	return(ret);
}

/*
 * This function 'normalizes' a single argument: it puts single quotes around
 * it and escapes other special characters. If quote is false, it just
 * returns its argument.
 * Bash only needs special treatment for single quotes; tcsh also recognizes
 * exclamation marks within single quotes, and nukes whitespace.
 * This function returns a pointer to a buffer that is overwritten by 
 * each call.
 */
const char *normalize(const char *arg)
{
	static char *BUFFER=NULL;
	const char *argptr=arg;
	char *bufptr;

	if (BUFFER != NULL)
		free(BUFFER);

	if (!quote) { /* Just copy arg */
		BUFFER=our_malloc(strlen(arg)+1);
			
		strcpy(BUFFER,arg);
		return BUFFER;
	}

	/* Each character in arg may take upto four characters in the result:
	   For a quote we need a closing quote, a backslash, a quote and an
	   opening quote! We need also the global opening and closing quote,
	   and one extra character for '\0'. */
	BUFFER=our_malloc(strlen(arg)*4+3);

	bufptr=BUFFER;
	*bufptr++='\'';

	while (*argptr) {
		if (*argptr == '\'') {
			/* Quote: replace it with: '\'' */
			*bufptr++='\'';
			*bufptr++='\\';
			*bufptr++='\'';
			*bufptr++='\'';
		} else if (shell==TCSH && *argptr=='!') {
			/* Exclamation mark: replace it with: \! */
			*bufptr++='\'';
			*bufptr++='\\';
			*bufptr++='!';
			*bufptr++='\'';
		} else if (shell==TCSH && *argptr=='\n') {
			/* Newline: replace it with: \n */
			*bufptr++='\\';
			*bufptr++='n';
		} else if (shell==TCSH && isspace(*argptr)) {
			/* Non-newline whitespace: replace it with \<ws> */
			*bufptr++='\'';
			*bufptr++='\\';
			*bufptr++=*argptr;
			*bufptr++='\'';
		} else
			/* Just copy */
			*bufptr++=*argptr;
		argptr++;
	}
	*bufptr++='\'';
	*bufptr++='\0';
	return BUFFER;
}

/* 
 * Generate the output. argv[0] is the program name (used for reporting errors).
 * argv[1..] contains the options to be parsed. argc must be the number of
 * elements in argv (ie. 1 if there are no options, only the program name),
 * optstr must contain the short options, and longopts the long options.
 * Other settings are found in global variables.
 */
int generate_output(char * argv[],int argc,const char *optstr,
                    const struct option *longopts)
{
	int exit_code = 0; /* We assume everything will be OK */
	int opt;
	int longindex;
	const char *charptr;

	if (quiet_errors) /* No error reporting from getopt(3) */
		opterr=0;
	optind=0; /* Reset getopt(3) */

#ifdef HAVE_GETOPT_LONG_ONLY
	while ((opt = (alternative?
	              getopt_long_only(argc,argv,optstr,longopts,&longindex):
#else
	while ((opt = (
#endif
                      getopt_long(argc,argv,optstr,longopts,&longindex))) 
               != EOF) 
		if (opt == '?' || opt == ':' )
			exit_code = 1;
		else if (!quiet_output) 
		{
			if (opt == LONG_OPT) {
				printf(" --%s",longopts[longindex].name);
				if (longopts[longindex].has_arg) 
					printf(" %s",
					       normalize(optarg?optarg:""));
			} else if (opt == NON_OPT) 
				printf(" %s",normalize(optarg)); 
			else {
				printf(" -%c",opt);
				charptr = strchr(optstr,opt);
				if (charptr != NULL && *++charptr == ':')
					printf(" %s",
					       normalize(optarg?optarg:""));
			}
		}
	
	if (! quiet_output) {
		printf(" --");
		while (optind < argc) 
			printf(" %s",normalize(argv[optind++]));
		printf("\n");
	}
	return exit_code;
}

/*
 * Report an error when parsing getopt's own arguments.
 * If message is NULL, we already sent a message, we just exit with a helpful
 * hint.
 */
void parse_error(const char *message)
{
	if (message)
		fprintf(stderr,"getopt: %s\n",message);
	fputs(_("Try `getopt --help' for more information.\n"),stderr);
	exit(2);
}

static struct option *long_options=NULL;
static int long_options_length=0; /* Length of array */
static int long_options_nr=0; /* Nr of used elements in array */
#define LONG_OPTIONS_INCR 10
#define init_longopt() add_longopt(NULL,0)

/* Register a long option. The contents of name is copied. */
void add_longopt(const char *name,int has_arg)
{
	char *tmp;
	if (!name) { /* init */
		free(long_options);
		long_options=NULL;
		long_options_length=0;
		long_options_nr=0;
	}

	if (long_options_nr == long_options_length) {
		long_options_length += LONG_OPTIONS_INCR;
		long_options=our_realloc(long_options,
		                         sizeof(struct option) * 
		                           long_options_length);
	}

	long_options[long_options_nr].name=NULL;
	long_options[long_options_nr].has_arg=0;
	long_options[long_options_nr].flag=NULL;
	long_options[long_options_nr].val=0;

	if (long_options_nr) { /* Not for init! */
		long_options[long_options_nr-1].has_arg=has_arg;
		long_options[long_options_nr-1].flag=NULL;
		long_options[long_options_nr-1].val=LONG_OPT;
		tmp = our_malloc(strlen(name)+1);
		strcpy(tmp,name);
		long_options[long_options_nr-1].name=tmp;
	}
	long_options_nr++;
}
	

/* 
 * Register several long options. options is a string of long options, 
 * separated by commas or whitespace. 
 * This nukes options! 
 */
void add_long_options(char *options)
{
	int arg_opt;
	char *tokptr=strtok(options,", \t\n");
	while (tokptr) {
		arg_opt=no_argument;
		if (strlen(tokptr) > 0) {
			if (tokptr[strlen(tokptr)-1] == ':') {
				if (tokptr[strlen(tokptr)-2] == ':') {
					tokptr[strlen(tokptr)-2]='\0';
					arg_opt=optional_argument;
				} else {
					tokptr[strlen(tokptr)-1]='\0';
					arg_opt=required_argument;
				}
				if (strlen(tokptr) == 0)
					parse_error(_("empty long option after "
					              "-l or --long argument"));
			}
			add_longopt(tokptr,arg_opt);
		}
		tokptr=strtok(NULL,", \t\n");
	}
}

void set_shell(const char *new_shell)
{
	if (!strcmp(new_shell,"bash"))
		shell=BASH;
	else if (!strcmp(new_shell,"tcsh"))
		shell=TCSH;
	else if (!strcmp(new_shell,"sh"))
		shell=BASH;
	else if (!strcmp(new_shell,"csh"))
		shell=TCSH;
	else
		parse_error(_("unknown shell after -s or --shell argument"));
}

void print_help(void)
{
	fputs(_("Usage: getopt optstring parameters\n"),stderr);
	fputs(_("       getopt [options] [--] optstring parameters\n"),stderr);
	fputs(_("       getopt [options] -o|--options optstring [options] [--]\n"),stderr);
	fputs(_("              parameters\n"),stderr);
#ifdef HAVE_GETOPT_LONG_ONLY
	fputs(_("  -a, --alternative            Allow long options starting with single -\n"),stderr);
#endif
	fputs(_("  -h, --help                   This small usage guide\n"),stderr);
	fputs(_("  -l, --longoptions=longopts   Long options to be recognized\n"),stderr);
	fputs(_("  -n, --name=progname          The name under which errors are reported\n"),stderr);
	fputs(_("  -o, --options=optstring      Short options to be recognized\n"),stderr);
	fputs(_("  -q, --quiet                  Disable error reporting by getopt(3)\n"),stderr);
	fputs(_("  -Q, --quiet-output           No normal output\n"),stderr);
	fputs(_("  -s, --shell=shell            Set shell quoting conventions\n"),stderr);	
	fputs(_("  -T, --test                   Test for getopt(1) version\n"),stderr);
	fputs(_("  -u, --unqote                 Do not quote the output\n"),stderr);
	fputs(_("  -V, --version                Output version information\n"),stderr);
	exit(2);
}
	
/* Exit codes:
 *   0) No errors, succesful operation.
 *   1) getopt(3) returned an error.
 *   2) A problem with parameter parsing for getopt(1).
 *   3) Internal error, out of memory
 *   4) Returned for -T
 */

static struct option longopts[]={ {"options",required_argument,NULL,'o'},
                                  {"longoptions",required_argument,NULL,'l'},
                                  {"quiet",no_argument,NULL,'q'},
                                  {"quiet-output",no_argument,NULL,'Q'},
                                  {"shell",required_argument,NULL,'s'},
                                  {"test",no_argument,NULL,'T'},
                                  {"unquoted",no_argument,NULL,'u'},
                                  {"help",no_argument,NULL,'h'},
#ifdef HAVE_GETOPT_LONG_ONLY
                                  {"alternative",no_argument,NULL,'a'},
#endif
                                  {"name",required_argument,NULL,'n'},
                                  {"version",no_argument,NULL,'V'},
                                  {NULL,0,NULL,0}
                                };

/* Stop scanning as soon as a non-option argument is found! */
static const char *shortopts="+ao:l:n:qQs:TuhV";

int main(int argc, char *argv[])
{
	char *optstr=NULL;
	char *name=NULL;
	int opt;
	int compatible=0;

	init_longopt();

	if (getenv("GETOPT_COMPATIBLE")) 
		compatible=1;

	if (argc == 1) 
	{
		if (compatible) {
			/* For some reason, the original getopt gave no error
                           when there were no arguments. */
			printf(" --\n");
			exit(0);
		}
		else
			parse_error(_("missing optstring argument"));
	}
	
	if (argv[1][0] != '-' || compatible) {
		quote=0;
		optstr=our_malloc(strlen(argv[1])+1);
		strcpy(optstr,argv[1]+strspn(argv[1],"-+"));
		argv[1]=argv[0];
		exit(generate_output(argv+1,argc-1,optstr,long_options));
	}
	
	while ((opt=getopt_long(argc,argv,shortopts,longopts,NULL)) != EOF) 
		switch (opt) {
#ifdef HAVE_GETOPT_LONG_ONLY
		case 'a':
			alternative=1;
			break;
#endif
		case 'h':
			print_help();
			exit(0);
		case 'o':
			if (optstr)
				free(optstr);
			optstr=our_malloc(strlen(optarg)+1);
			strcpy(optstr,optarg);
			break;
		case 'l':
			add_long_options(optarg);
			break;
		case 'n':
			if (name)
				free(name);
			name=our_malloc(strlen(optarg)+1);
			strcpy(name,optarg);
			break;
		case 'q':
			quiet_errors=1;
			break;
		case 'Q':
			quiet_output=1;
			break;
		case 's':
			set_shell(optarg);
			break;
		case 'T':
			exit(4);
		case 'u':
			quote=0;
			break;
		case 'V':
			printf(_("getopt (enhanced) 1.1.2\n"));
			exit(0);
		case '?':
		case ':':
			parse_error(NULL);
		default:
			parse_error(_("internal error, contact the author."));
		}
	
	if (!optstr) 
	{
		if (optind >= argc)
			parse_error(_("missing optstring argument"));
		else {
			optstr=our_malloc(strlen(argv[optind])+1);
			strcpy(optstr,argv[optind]);
			optind++;
		}
	}
	if (name)
		argv[optind-1]=name;
	else
		argv[optind-1]=argv[0];
	exit(generate_output(argv+optind-1,argc-optind+1,optstr,long_options));
}

[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[Nicholas Wourms]

Egor,

Thanks for the utils, very helpful indeed!  Perhaps Charles should add
them to Cygutils since, ATM, they don't fit anywhere else but do serve a
useful purpose?

Cheers,
Nicholas
--- egor duda <deo@logos-m.ru> wrote:
> Hi!
> 
> Tuesday, 04 June, 2002 Christopher Faylor cgf@redhat.com wrote:
> 
> >>       *       On my production system, I had to change the
> '#!/bin/sh' to
> >>               '#!/bin/bash' on one of the mknetrel shell scripts
> >>               to get the shell to accept the usage of getopts ... but
> on the
> >>               fresh install, I did not.  (This is the bash getopts
> builtin,
> >>               not the standalone and singular 'getopt' discussed
> above)
> 
> CF> Yes, I have never run this under cygwin, actually.  It was intended
> as a
> CF> cross-compilation environment.  I'm surprised that it works on
> cygwin
> CF> with so few changes.
> 
> I'm running it on cygwin. All i need is to build getopt.exe and
> readlink.exe from two attached source files. readlink.c is taken from
> OpenBSD cvs, and getopt.c is slightly patched version of getopt.c from
> linux-utils. They both can be built out-of-the-box.
> 
> Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

> ATTACHMENT part 2 application/octet-stream name=readlink.c


> ATTACHMENT part 3 application/octet-stream name=getopt.c
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[Charles Wilson]

egor duda wrote:

> Hi!
> 
> Tuesday, 04 June, 2002 Christopher Faylor cgf@redhat.com wrote:
> 
> 
>>>      *       On my production system, I had to change the '#!/bin/sh' to
>>>              '#!/bin/bash' on one of the mknetrel shell scripts
>>>              to get the shell to accept the usage of getopts ... but on the
>>>              fresh install, I did not.  (This is the bash getopts builtin,
>>>              not the standalone and singular 'getopt' discussed above)
>>>
> 
> CF> Yes, I have never run this under cygwin, actually.  It was intended as a
> CF> cross-compilation environment.  I'm surprised that it works on cygwin
> CF> with so few changes.
> 
> I'm running it on cygwin. All i need is to build getopt.exe and
> readlink.exe from two attached source files. readlink.c is taken from
> OpenBSD cvs, and getopt.c is slightly patched version of getopt.c from
> linux-utils. They both can be built out-of-the-box.


Hmm...these seem like useful additions, and since getopt.exe is from 
linux-utils:

should readlink and getopt be added to cygutils?  </fear full.exe>

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[Christopher Faylor]

On Tue, Jun 04, 2002 at 10:25:57AM +0400, egor duda wrote:
>Hi!
>
>Tuesday, 04 June, 2002 Christopher Faylor cgf@redhat.com wrote:
>
>>>       *       On my production system, I had to change the '#!/bin/sh' to
>>>               '#!/bin/bash' on one of the mknetrel shell scripts
>>>               to get the shell to accept the usage of getopts ... but on the
>>>               fresh install, I did not.  (This is the bash getopts builtin,
>>>               not the standalone and singular 'getopt' discussed above)
>
>CF> Yes, I have never run this under cygwin, actually.  It was intended as a
>CF> cross-compilation environment.  I'm surprised that it works on cygwin
>CF> with so few changes.
>
>I'm running it on cygwin. All i need is to build getopt.exe and
>readlink.exe from two attached source files. readlink.c is taken from
>OpenBSD cvs, and getopt.c is slightly patched version of getopt.c from
>linux-utils. They both can be built out-of-the-box.

FWIW, I've eliminated the need for getopt and (I hope) readlink in the
cvs version of mknetrel.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[rich-paul]

> Yes, I have never run this under cygwin, actually.  It was intended as a
> cross-compilation environment.  I'm surprised that it works on cygwin
> with so few changes.
Great work, my shell scripts require alot of TLC and SSH b4 they work on
more than one platform.  <G>

> You should be able to say "mknetrel cygwin" to have it build the latest version.
> Again, I'm surprised that it would actually work with explicit versions.

I'm sorry, I didn't use explicit versions when calling mknetrel.  I was
saying that the wildcards in the shell snippets above (e.g. cd
cygwin*/winsup) would break if there was, for example, more than one dir
called 'cygwin*'.  Actually, it's worse than I thought, I didn't put a
dash b4 the glob, so even a package called cygwinfoo-2-3 would break the
cd!

-- 
Got freedom?  Vote Libertarian:  http://www.lp.org

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[Nicholas Wourms]

--- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> 
> 
> egor duda wrote:
> 
> > Hi!
> > 
> > Tuesday, 04 June, 2002 Christopher Faylor cgf@redhat.com wrote:
> > 
> > 
> >>>      *       On my production system, I had to change the
> '#!/bin/sh' to
> >>>              '#!/bin/bash' on one of the mknetrel shell scripts
> >>>              to get the shell to accept the usage of getopts ... but
> on the
> >>>              fresh install, I did not.  (This is the bash getopts
> builtin,
> >>>              not the standalone and singular 'getopt' discussed
> above)
> >>>
> > 
> > CF> Yes, I have never run this under cygwin, actually.  It was
> intended as a
> > CF> cross-compilation environment.  I'm surprised that it works on
> cygwin
> > CF> with so few changes.
> > 
> > I'm running it on cygwin. All i need is to build getopt.exe and
> > readlink.exe from two attached source files. readlink.c is taken from
> > OpenBSD cvs, and getopt.c is slightly patched version of getopt.c from
> > linux-utils. They both can be built out-of-the-box.
> 
> 
> Hmm...these seem like useful additions, and since getopt.exe is from 
> linux-utils:
> 
> should readlink and getopt be added to cygutils?  </fear full.exe>
> 
Chuck,

As I mentioned earlier, they probably should, as they are YAE of those
small miscellaneous shell utilities you probably never think you'll use
but then one day realize you need them for some script you are writing :).
 Seriously, though, it would probably be useful to have these, not quite
as useful as a full port of glibc, but, nonetheless, useful in their own
way.  Anyone else feel this way?

Cheers,
Nicholas
 

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Building cygwin1.dll and mknetrel

[Nicholas Wourms]

--- Charles Wilson <cwilson@ece.gatech.edu> wrote:
> 
> 
> egor duda wrote:
> 
> > Hi!
> > 
> > Tuesday, 04 June, 2002 Christopher Faylor cgf@redhat.com wrote:
> > 
> > 
> >>>      *       On my production system, I had to change the
> '#!/bin/sh' to
> >>>              '#!/bin/bash' on one of the mknetrel shell scripts
> >>>              to get the shell to accept the usage of getopts ... but
> on the
> >>>              fresh install, I did not.  (This is the bash getopts
> builtin,
> >>>              not the standalone and singular 'getopt' discussed
> above)
> >>>
> > 
> > CF> Yes, I have never run this under cygwin, actually.  It was
> intended as a
> > CF> cross-compilation environment.  I'm surprised that it works on
> cygwin
> > CF> with so few changes.
> > 
> > I'm running it on cygwin. All i need is to build getopt.exe and
> > readlink.exe from two attached source files. readlink.c is taken from
> > OpenBSD cvs, and getopt.c is slightly patched version of getopt.c from
> > linux-utils. They both can be built out-of-the-box.
> 
> 
> Hmm...these seem like useful additions, and since getopt.exe is from 
> linux-utils:
> 
> should readlink and getopt be added to cygutils?  </fear full.exe>
> 
Chuck,

As I mentioned earlier, they probably should, as they are YAE of those
small miscellaneous shell utilities you probably never think you'll use
but then one day realize you need them for some script you are writing :).
 Seriously, though, it would probably be useful to have these, not quite
as useful as a full port of glibc, but, nonetheless, useful in their own
way.  Anyone else feel this way?

Cheers,
Nicholas
 

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/