First startup of cygwin (bash) is terribly slow

[Bertalan Fodor]

Hello,
every day I turn on my computer and run cygwin (i.e. bash), it starts up 
terribly slow. The second time or when there is an open instance of 
bash, it starts up fast.

Do you have any ideas why this happens?
Bert
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Lame 3.96.1 compilation

[Reini Urban]

Al Bogner schrieb:
As mentioned a few postings before I am new to cygwin und I am 
unsure, If I installed all packages I need to compile lame.
Do you really want the cygwin lame and not the mingw version?
The lame people usually just build the mingw target (they want it to run 
fast). And then with the latest mingw gcc and winapi build (from 
mingw.org), which is much newer (3.4.x) than our cygwin-mingw version 
here (3.3.1). Your error looks like you need a recent mingw winapi.

./configure did not end with an error, but I got this message:
"configure: WARNING: winsock2.h: present but cannot be compiled"
make ended with these lines:
if gcc -DHAVE_CONFIG_H  -I. -I. -I.. -I../libmp3lame -I../include 
-I..-O3  -ffast-math 			-funroll-loops 
-maccumulate-outgoing-args -Wall -pipe-MT brhist.o -MD -MP 
-MF ".deps/brhist.Tpo" \
  -c -o brhist.o `test -f 'brhist.c' || echo './'`brhist.c; \
then mv -f ".deps/brhist.Tpo" ".deps/brhist.Po"; \
else rm -f ".deps/brhist.Tpo"; exit 1; \
fi
brhist.c:65:20: term.h: No such file or directory
brhist.c: In function `brhist_init':
brhist.c:160: warning: implicit declaration of function `tgetent'
brhist.c:165: warning: implicit declaration of function `tgetnum'
brhist.c:173: warning: implicit declaration of function `tgetstr'
brhist.c:173: warning: assignment makes pointer from integer without 
a cast
brhist.c:178: warning: assignment makes pointer from integer without 
a cast
brhist.c:183: warning: assignment makes pointer from integer without 
a cast
brhist.c:188: warning: assignment makes pointer from integer without 
a cast
make[2]: *** [brhist.o] Error 1
make[2]: Leaving directory `/usr/src/lame-3.96.1/frontend'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/lame-3.96.1'
make: *** [all] Error 2

The whole output of configure and make is attached, as well as 
cygcheck.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Some contacts phones at Bangalore-India for cygwin features

[Mk Sanganagouda-A5730C]

Hi,

I have some queries on cygwin, where i would like to now the features and use for my 
requirement as porting UNIX based applications to Windows.

Please give some contact phone numbers and some person names who are worked on cygwin 
in Bangalore- India.


Regards,
Kittur

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

inetd problem on Windows NT (inetutils 1.3.2-28)

[Frank Mahler]

Hello list!

I have a problem regarding inetd service under Windows NT 4 (SP6).

At first, I wasn't able to start the inetd service. After running 
inetd --install-as-service I got a service named CYGWIN inetd
in Services. But the service won't find its inetd.conf file, although
it's placed in /etc/inetd.conf (which is natively 
E:\cygwin\etc\inetd.conf on this machine).

I found out, that placing an \etc directory on the same drive where
WINNT lies, would help. So I placed a file in D:\etc\inetd.conf.

I configured the only line in inetd.conf:

ascostart stream tcp nowait root /bin/ascostart

that is intented to start a service (named asco) on the machine,
when getting a request on port ascostart (which is 2719 here). After
executing a

nc -zv localhost ascostart

I don't get a connection refused error. That's why I think, everything
should be fine and inetd found its configuration file.

Unfortunately the script /bin/ascostart isn't run. In Event Viewer I see
the error message:

The description for Event ID ( 0 ) in Source ( inetd ) could not
be found. It contains the following insertion string(s): inetd :
PID 293 : cannot execute /bin/ascostart: No such file or
directory.

But the file is there!

I even tried configuring

ascostart stream tcp nowait root net start asco

or

ascostart stream tcp nowait root cmd.exe /c "net start asco"

or

ascostart stream tcp nowait root cmd.exe /c "ascostart.cmd"

where in the latter the ascostart.cmd were in D:\WINNT\system32
which is in the system's path variable.

In these cases, I don't get an error in Event Viewer, but the service will
not start, nor do I get other messages, what might went wrong.

I already established a CYGWIN environment variable filled with ntsec as
stated somewhere on the list, with no effort! And of course I rebooted the
machine.

And: On another machine everything is ok!

Do you have any hints, what I can do to find out what's going wrong here?

Below is cygcheck output...

Any help is greatfully appreciated!

Best regards,

Frank Mahler
--8<--8<--8<--8<--8<--

Cygwin Configuration Diagnostics
Current System Time: Tue Aug 10 14:50:19 2004

Windows NT Ver 4.0 Build 1381 Service Pack 6

Path:   E:\cygwin\usr\local\bin
E:\cygwin\bin
E:\cygwin\bin
E:\cygwin\usr\X11R6\bin
d:\Oracle\Ora817\bin
d:\Program Files\Oracle\jre\1.1.7\bin
d:\Oracle\Ora81\bin
d:\WINNT\system32
d:\WINNT
d:\WINNT\System32\patrol\bin
d:\WINNT\System32\patrol\utils
d:\WINNT\System32\patrol\KM\bin
d:\Program Files\Symantec\pcAnywhere
.\
d:\ORANT\BIN
.\
d:\Program Files\Mts
d:\WINNT\System32\WBEM
E:\cygwin\bin

Output from E:\cygwin\bin\id.exe (nontsec)
UID: 1002(SADMIN) GID: 513(None)
513(None)

Output from E:\cygwin\bin\id.exe (ntsec)
UID: 1002(SADMIN) GID: 513(None)
0(root)  513(None)
544(Administrators)  545(Users)   1006(LG_SIEBEL_FS)
1001(PC-Anywhere)

SysDir: D:\WINNT\System32
WinDir: D:\WINNT

CYGWIN = `ntsec'
HOME = `E:\cygwin\home\SADMIN'
MAKE_MODE = `unix'
PWD = `/home/SADMIN'
USER = `SADMIN'

COMPUTERNAME = `F8935'
COMSPEC = `D:\WINNT\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
HOMEDRIVE = `D:'
HOMEPATH = `\'
HOSTNAME = `f8935'
INCLUDE = `D:\Program Files\Mts\Include'
INFOPATH = 
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LIB = `D:\Program Files\Mts\Lib'
LOGONSERVER = `\\F8935'
MANPATH = 
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/usr/bin'
OS2LIBPATH = `D:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.JS;.VBE;.JSE;.WSF;.WSH'
PATROL_ADMIN = `patrol'
PATROL_HOME = `D:\WINNT\System32\patrol'
PATROL_TEMP = `D:\WINNT\System32\patrol\tmp'
PFC_HOME = `D:\WINNT\System32\pfc'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 1 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0109'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SHLVL = `1'
SYSTEMDRIVE = `D:'
SYSTEMROOT = `D:\WINNT'
TEMP = `D:\TEMP'
TERM = `cygwin'
TMP = `D:\TEMP'
TMP_PATROL = `D:\WINNT\System32\patrol\tmp'
USERDOMAIN = `F8935'
USERNAME = `sadmin'
USERPROFILE = `D:\WINNT\Profiles\sadmin'
WINDIR = `D:\WINNT'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0

Re: i see no perl executable around there

[Gerrit P. Haase]

Hello Steve,

Am Dienstag, 10. August 2004 um 05:23 schriebst du:

> I downloaded perl5.8.5:
> % perl --version

> This is perl, v5.8.5 built for cygwin-thread-multi-64int

> Copyright 1987-2004, Larry Wall

> When I tried to build Compress::Zlib manually, I got the message:

> LD_RUN_PATH="" ld2  -s -L/usr/local/lib Zlib.o adler32.o compress.o 
> crc32.o gzio.o uncompr.o deflate.o trees.o zutil.o inflate.o infblock.o
> inftrees.o infcodes.o infutil.o inffast.o   -o 
> blib/arch/auto/Compress/Zlib/Zlib.dll  
> /usr/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/libperl.dll.a
> i see no perl executable around there
> perl is required to build dynamic libraries
> go fetch one or build this one static
> MAKE: *** [blib/arch/auto/Compress/Zlib/Zlib.dll] Error 1

> Any idea what the problem is?

ld2 is broken (for you), it should contain s.th. like this:

for trythis in /usr/bin/perl
do
  if [ -x $trythis ]
  then
$trythis /usr/bin/perlld "$@"
exit $?
  fi
done
# hard luck!
echo I see no perl executable around there
...
exit 1

It is used during perl builds, that means the previously installed ld2
in /usr/bin is overwritten during the build since the build needs ld2
containing a reference to the newly created perl instead of the old
perl.  If the old ld2 is in PATH it would be picked up at first and
therefore it was needed to write in the system directory during the
build.

If you finish a perl build the make install step will fix the ld2 to
contain what the release version contains, if you don't install perl
into /usr/bin, it needs manually fixing.  Isn't this already in the
README.cygwin (aka perldoc perlcygwin) included?


Gerrit
-- 
=^..^=



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

Re: Some contacts phones at Bangalore-India for cygwin features

[Corinna Vinschen]

On Aug 10 18:31, Mk Sanganagouda-A5730C wrote:
> Hi,
> 
> I have some queries on cygwin, where i would like to now the features and use for my 
> requirement as porting UNIX based applications to Windows.
> 
> Please give some contact phone numbers and some person names who are worked on 
> cygwin in Bangalore- India.

[EMAIL PROTECTED] is a public mailing list, so I'm wondering if you really
intended to send this posting here. 

If you just want help and information about technical issues, you're fine
with sending your specific requests to this public list. 

If you're going to port proprietary software from UNIX to Cygwin, I'd like
to point you to the licensing page of the Cygwin project first:

  http://cygwin.com/licensing.html

Please note especially that you must release your software under an
Open Source License unless you purchase a Cygwin license at Red Hat Inc.

If you need further contact to Red Hat for inquiries about licensing and
pricing of the Cygwin license, I'd like to point you to this web page:

  http://www.redhat.com/software/cygwin/


Hope that helps,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Co-Project Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: i see no perl executable around there

[Gerrit P. Haase]

Hello Steve,

[...]

> If you finish a perl build the make install step will fix the ld2 to
> contain what the release version contains, if you don't install perl
> into /usr/bin, it needs manually fixing.  Isn't this already in the
> README.cygwin (aka perldoc perlcygwin) included?

If you use a prefix other than /usr/bin to build perl yourself and the
other path comes first in the PATH setting, the broken ld2 may also be
there (e.g. /usr/local/bin/ld2).


Gerrit
-- 
=^..^=



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

ImageMagick

[c . m . reveley]

Hi -
I'm getting a problem with ImageMagick 6.0.3-1
I am having the same
assertion "list_info != (LinkedListInfo *) NULL" failed: file 
"/home/harold/ports/ImageMagick/ImageMagick-6.0.3/magick/hashmap.c", line 
1033
Aborted (core dumped)

error that has already been noted on this list. I've tried the few 
solutions mentioned on the list but to no avail.

I really, really, need to get this to work!!
although its offtopic, if anyone knows of another way of converting a X 
bitmap (.xbm) to an .eps file for inclusion in a LaTeX document I'd be most 
most grateful. The native win32 ImageMagick does not seem to work; it 
creates a dodgy .eps file that nothing can read, including itself.


thanks,
Colin Reveley 

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

Re: zmodem port?

[Scott Evans]

On Wed Aug 4, Jerry Williams wrote:
> I searched earlier posts, and it is clear that it had been done. So
> I tried grabbing rzsz.sip from www.omen.com and building it. No
> problem. Just modify the makefile to add .exe to the executable
> names when calling ln. I attached the "diff -c" output so you can
> patch it. This adds a new "cygwin" target.
> [..]
> In fact, zssh comes with another flavor of rz/sz that builds just
> fine via ./configure && make.

Hey now!  Cool.

The omen.com version indeed works, though its rz exits a bit strangely.
I didn't know about zssh (neat idea), but their ssh is from the lrzsz
project; that's the one that I have built in the past.  Its rz doesn't
seem to work quite right.

Anyway, thanks for the diff -- I'll try the omen version for a while
and see how I do.



scott

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

Re: C compiler cannot create executables

[Igor Pechtchanski]

On Mon, 9 Aug 2004, Al Bogner wrote:

> Am Sonntag, 8. August 2004 22:55 schrieb Igor Pechtchanski:
> > so, check that a simple "hello world" program can be
> > compiled with gcc and executed.
>
> As written in the other mail in this thread, binutils helped, but I
> tried 3 other packages (lame, smake and cdrtools) and I had
> problems with all 3. See new thread..
>
> Sorry, I did a lot of bash scripts, but never coded in C. So do you
> have a link, where I can read how to do make a simple "hello world"
> program or can you explain in a few lines, what I have to do. I
> assume it is very simple.

- CUT HERE -
#include 
int main(int ac, char *av[]) { printf("Hello world\n"); return 0; }
--- Warning: cutting here may damage your screen surface ---

> > Oh, and in the future, please *attach* the output of cygcheck
>
> Sorry, it is the first mailinglist I am subscribed, which wants
> attachments.

See

> Problem reports:   http://cygwin.com/problems.html

HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

[ANNOUNCEMENT] Updated: CMake-2.0.3-1

[William A. Hoffman]

There has been a new release of the official cmake (2.0.3-1).
This is a minor release from to 2.0.2 to 2.0.3.

Changes in CMake 2.0.3:

- Fixes for Find/Use SWIG, better error reporting and SWIG_FLAGS work.
- initial support for VCExpress visual studio 8
- LastMemCheck.log instead of LastMemCheck.xml
- timeout for ctest build and run
- Fixes for MinGW EXEC_COMMAND
- Fixes for install on windows, to work with Release/Debug dirs
- Fixes for install to work with shared library versions
- Fixes for QT wrapping commands to not require QT_WRAP_UI to be set, but still set it
- Better error reporting for win32 process running
- PreLoad.cmake file can be in source or binary
- Tree killing for linux and ctest
- CMAKE_PROGRAM_PATH CMAKE_FILE_PATH now searched by FIND_PROGRAM and FIND_FILE
- FLTK FLTK_WRAP_UI now set for backwards compatibility
- More warning expressions for ctest
- Do not duplicate include flags for .rc files on windows.
- fix spelling errors in error messages
- report build directory used in command line cmake
- fix for bug 981, help in ccmake lost cursor position
- CMakeSetup browse buttons use current directories
- generated test driver programs flush the text menu
- Mentioned LOCATION target property in GET_TARGET_PROPERTY documentation
- Added warning to AUX_SOURCE_DIRECTORY command documentation.
- Fix BUG 971: command line cmake does not select good default generator.
- Fix BUG 999: Allow a project to define system name for dart submissions
- Fix BUG 997:  CTest cannot handle URLs which contain a "?"
- Add support to ctest for reporting timing information.
- Fix BUG 966 VC7 generator correctly converts command line flags to GUI options.
- Fixed link-libs commands to not crash when last argument is debug/optimized.

Changes in CMake 2.0.2:

- Remove automatic -I for source directory with makefile generator.
  Problems caused by this can be fixed with this command:
  INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}).
  Or, you can set the CMAKE_BACKWARDS_COMPATIBILITY to 1.8.
- Fixed parsing of unquoted arguments to allow double-quotes within the
  argument.
- Add a STREQUAL to the IF command.
- Modules/FindFLTK.cmake: look for both Fl.h or Fl.H.
- Fix compound IF crash on unix. BUG id 917.
- Fix path problem with sub projects and IDE workspace files.
- Add a FindKDE module.
- Modules/FindFLTK.cmake: fix for bug 915
- BUG#891: When building CMake itself, use the new cmake to install so 
  that the current cmake can be overwritten.
- BUG: Files in top-level directory of source tree were not reported in updates log 
  for ctest.
- Fix find library so it does not find directories.


Changes in CMake 2.0.1:

- Platform independent Install (no more install-sh); 
  supports pre install, post install, manifest, destdir...
  faster and it works on Windows 
- Add support for SWIG
- Optional support for relative paths
- INCLUDE and FIND_PACKAGE both check CMAKE_MODULE_PATH 
- IF command supports better expression support, like IF(A AND B AND C)
- IF command now has a numeric EQUAL test
- MACRO's now support variable arguments
- FOREACH supports a RANGE of values genertor
- CMake supports an automatic pre-load cmake file in the source tree of a project.
- GET_TARGET_PROPERTY can give you the build location of a target.
- Loaded commands have a crash signal handler to detect crashes not caused by cmake.
- GET/SET_DIRECTORY_PROPERTY/PROPERTIES commands so that we can change include 
directories
  and get all sorts of things. 
- VERBOSE build option for visual studio IDE generators.
- FIND_LIBRARY and FIND_PATH now look in CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH
  environment variables in addition to and before the PATH environment variable.
- Each sub project in a project now creates a top level IDE project file so it can
  be loaded independently.
- A saftey chech was added to make sure that files written using WRITE_FILE 
  and FILE WRITE are not used as input files which can lead to infinite loops in the 
build.
- Add support for adding object files and sources. This way you can use external 
  program such as assembler or fortran to generate object files. Also star of 
  fixing: Bug #757
- add .o file as a source file.
- New REMOVE_DEFINITION command, opposite to ADD_DEFINITIONS.
- CCmake support for HOME and END keys. Also fix Bug #666, in CCMake when deleting
  something, it does not stop at the beginning of line.
- Fix externl projects for VS7 and VS6.
- New support for import of modules without specifying a path.
- New testing option to build and run an executable --build-and-test.
- Support for shared library versions on UNIX.
- SUBDIR command now supports PREORDER build option.
- Add support for file names with +-~ in them for borland compiler.
- Mac OSX bundle executable creation support with the ADD_EXECUTABLE command.
- CTest Support for in-source builds.
- CTest Skip tests that do not have defects.
- CTest new option -I that adds the ability to run a limited sub-set of the tests.
- CTest suppo

Re: Lame 3.96.1 compilation (Attn: libncurses-devel maintainer)

[Igor Pechtchanski]

On Mon, 9 Aug 2004, Al Bogner wrote:

> As mentioned a few postings before I am new to cygwin und I am
> unsure, If I installed all packages I need to compile lame.
>
> ./configure did not end with an error, but I got this message:
> "configure: WARNING: winsock2.h: present but cannot be compiled"

Again, please see config.log (not the output of "configure") for the
actual problem.

> make ended with these lines:
> if gcc -DHAVE_CONFIG_H  -I. -I. -I.. -I../libmp3lame -I../include -I..-O3  
> -ffast-math-funroll-loops  
> -maccumulate-outgoing-args -Wall -pipe-MT brhist.o -MD -MP -MF 
> ".deps/brhist.Tpo" \
>   -c -o brhist.o `test -f 'brhist.c' || echo './'`brhist.c; \
> then mv -f ".deps/brhist.Tpo" ".deps/brhist.Po"; \
> else rm -f ".deps/brhist.Tpo"; exit 1; \
> fi
> brhist.c:65:20: term.h: No such file or directory

You do have libncurses-devel installed, which contains term.h, but you
don't seem to have /usr/include/term.h as a symlink to
/usr/include/ncurses/term.h.  I have this link on my machine, but the
latest postinstall script doesn't seem to create it.  This is likely a
packaging bug in the libncurses-devel package.  Chuck?

> brhist.c: In function `brhist_init':
> brhist.c:160: warning: implicit declaration of function `tgetent'
> brhist.c:165: warning: implicit declaration of function `tgetnum'
> brhist.c:173: warning: implicit declaration of function `tgetstr'

These stem from the above.

> brhist.c:173: warning: assignment makes pointer from integer without a cast
> brhist.c:178: warning: assignment makes pointer from integer without a cast
> brhist.c:183: warning: assignment makes pointer from integer without a cast
> brhist.c:188: warning: assignment makes pointer from integer without a cast

These are warnings, and won't stop the build.  I have a feeling they are
also the result of the above, but if they are still present once you have
a valid term.h, they should be investigated.

> make[2]: *** [brhist.o] Error 1
> make[2]: Leaving directory `/usr/src/lame-3.96.1/frontend'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/lame-3.96.1'
> make: *** [all] Error 2
>
> The whole output of configure and make is attached, as well as
> cygcheck.

HTH,
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

Re: setup.exe: Install from local directory failing

[Gerrit P. Haase]

Hallo sqweek,

Moved this to cygwin at cygwin dott com list.

[...cannot help with the setup problem...]

>  Now, a seperate question, regarding those extra packages I got in
> execution 1. For example, perl - I have ActivePerl, which is native
> windows, so I don't really want a cygwin version. Is it safe for me to
> just delete the perl files from my local install directory (so I don't
> have to conciously avoid installing perl when updating)? Or is there
> some kind of list of available packages maintained elsewhere I'd also
> need remove perl from?

There is
/etc/setup/perl.lst.gz
/etc/setup/perl_manpages.lst.gz 
zcat /etc/setup/perl.lst.gz
gives you a full list of all (via setup.exe) installed files from the
perl package.


Gerrit
-- 
=^..^=



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

Re: setup.exe: Install from local directory failing

[Igor Pechtchanski]

On Tue, 10 Aug 2004, Gerrit P. Haase wrote:

> Hallo sqweek,
>
> Moved this to cygwin at cygwin dott com list.
>
> [...cannot help with the setup problem...]
>
> >  Now, a seperate question, regarding those extra packages I got in
> > execution 1. For example, perl - I have ActivePerl, which is native
> > windows, so I don't really want a cygwin version. Is it safe for me to
> > just delete the perl files from my local install directory (so I don't
> > have to conciously avoid installing perl when updating)? Or is there
> > some kind of list of available packages maintained elsewhere I'd also
> > need remove perl from?
>
> There is
> /etc/setup/perl.lst.gz
> /etc/setup/perl_manpages.lst.gz
> zcat /etc/setup/perl.lst.gz
> gives you a full list of all (via setup.exe) installed files from the
> perl package.

Or simply use "cygcheck -l perl". :-)
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

Re: C compiler cannot create executables

[Gerrit P. Haase]

Hallo Al,

Am Montag, 9. August 2004 um 23:03 schriebst du:

> Am Sonntag, 8. August 2004 22:55 schrieb Igor Pechtchanski:
>> so, check that a simple "hello world" program can be
>> compiled with gcc and executed.

> As written in the other mail in this thread, binutils helped, but I 
> tried 3 other packages (lame, smake and cdrtools) and I had 
> problems with all 3. See new thread..

Schilling programs are always some kind of strange;)


Gerrit
-- 
=^..^=



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

Re: Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

Christopher Faylor wrote:
>On Thu, Aug 05, 2004 at 09:09:40AM +0200, Peter Ekberg wrote:
>>I have read several messages stating that dlopen does not work for
dlls
>>that depend on cygwin1.dll.
>>(e.g. http://sources.redhat.com/ml/cygwin/2004-06/msg01056.html).
>>I have also understood that this is due to some structures not being
>>initialized in that case.
>>
>>Is this dlopen problem limited to non-cygwin apps? I.e. is it true
>>that an app that depends directly on the cygwin1.dll is incapable of
>>dlopening dlls that depend on cygwin1.dll?
>
>No, it is not true.  dlopen would be pretty worthless if it didn't work
>in a standard cygwin program.

Indeed. Knowing that it should work, I was inspired to do some more
tests.

The reason I asked is that the following results in a dll that can't be
dlopened:

foo.c:
8<---
__declspec(dllexport) int foo(int bar);

int foo(int bar)
{
return bar;
}
8<---

Build commands:
$ gcc -c foo.c
$ dlltool --dllname pseudo_stubs.dll --exclude-symbols
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],DllMainCR
[EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
$ dllwrap --dllname pseudo_stubs.dll --output-lib pseudo_stubs.dll.a
--def foo.def foo.o -L/usr/lib

However, further tests have shown that if I change the name pseudo_stubs
to foo in the above commands, it works like a charm. Like this:

$ gcc -c foo.c
$ dlltool --dllname foo.dll --exclude-symbols
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],DllMainCR
[EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
$ dllwrap --dllname foo.dll --output-lib foo.dll.a --def foo.def foo.o
-L/usr/lib

I use this program to test whether the resulting dll works:

load.c
8<---
#include 
#include 

char *dlls[] = {
"pseudo_stubs.dll",
"foo.dll",
NULL
};

int main(void)
{ 
int i;
void *res;

for(i=0; dlls[i]; ++i) {
printf("%s\t", dlls[i]);
res=dlopen(dlls[i], RTLD_LAZY | RTLD_GLOBAL);
if(!res)
printf("%s\n", dlerror());
else
printf("ok\n");
}

return 0;
}
8<---

I build load.c with "gcc load.c -o load" and ./load produces this
output:
pseudo_stubs.dlldlopen: Win32 error 998
foo.dll ok

Any help on this would be appreciated.

Cheers,
Peter Ekberg



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

RE: Dynamic loading of cygwin dependent dlls

[Reid Thompson]

take the underscore out of the dll name

psuedo_stub -> psuedostub

reid


> -Original Message-
> From: Peter Ekberg [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 10, 2004 3:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Dynamic loading of cygwin dependent dlls
> 
> 
> Christopher Faylor wrote:
> >On Thu, Aug 05, 2004 at 09:09:40AM +0200, Peter Ekberg wrote:
> >>I have read several messages stating that dlopen does not work for
> dlls
> >>that depend on cygwin1.dll.
> >>(e.g. http://sources.redhat.com/ml/cygwin/2004-06/msg01056.html).
> >>I have also understood that this is due to some structures 
> not being 
> >>initialized in that case.
> >>
> >>Is this dlopen problem limited to non-cygwin apps? I.e. is it true 
> >>that an app that depends directly on the cygwin1.dll is 
> incapable of 
> >>dlopening dlls that depend on cygwin1.dll?
> >
> >No, it is not true.  dlopen would be pretty worthless if it 
> didn't work 
> >in a standard cygwin program.
> 
> Indeed. Knowing that it should work, I was inspired to do 
> some more tests.
> 
> The reason I asked is that the following results in a dll 
> that can't be
> dlopened:
> 
> foo.c:
> 8<---
> __declspec(dllexport) int foo(int bar);
> 
> int foo(int bar)
> {
>   return bar;
> }
> 8<---
> 
> Build commands:
> $ gcc -c foo.c
> $ dlltool --dllname pseudo_stubs.dll --exclude-symbols 
> [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
,DllMainCR
> [EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
> $ dllwrap --dllname pseudo_stubs.dll --output-lib 
> pseudo_stubs.dll.a --def foo.def foo.o -L/usr/lib
> 
> However, further tests have shown that if I change the name 
> pseudo_stubs to foo in the above commands, it works like a 
> charm. Like this:
> 
> $ gcc -c foo.c
> $ dlltool --dllname foo.dll --exclude-symbols 
> [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
,DllMainCR
> [EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
> $ dllwrap --dllname foo.dll --output-lib foo.dll.a --def 
> foo.def foo.o -L/usr/lib
> 
> I use this program to test whether the resulting dll works:
> 
> load.c
> 8<---
> #include 
> #include 
> 
> char *dlls[] = {
>   "pseudo_stubs.dll",
>   "foo.dll",
>   NULL
> };
> 
> int main(void)
> { 
>   int i;
>   void *res;
>   
>   for(i=0; dlls[i]; ++i) {
>   printf("%s\t", dlls[i]);
>   res=dlopen(dlls[i], RTLD_LAZY | RTLD_GLOBAL);
>   if(!res)
>   printf("%s\n", dlerror());
>   else
>   printf("ok\n");
>   }
> 
>   return 0;
> }
> 8<---
> 
> I build load.c with "gcc load.c -o load" and ./load produces this
> output:
> pseudo_stubs.dll  dlopen: Win32 error 998
> foo.dll   ok
> 
> Any help on this would be appreciated.
> 
> Cheers,
> Peter Ekberg
> 
> 

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

RE: Dynamic loading of cygwin dependent dlls

[Reid Thompson]

actually -- that's not it, as this code, gives the following results:

CODE---CODE
#include 
#include 

char *dlls[] = {
"pseudostubs.dll",
"foo.dll",
"psuedostubs.dll",
NULL
};

int main(void)
{ 
int i;
void *res;

for(i=0; dlls[i]; ++i) {
printf("%s\t", dlls[i]);
res=dlopen(dlls[i], RTLD_LAZY | RTLD_GLOBAL);
if(!res)
printf("%s\n", dlerror());
else
printf("ok\n");
}

return 0;
}
RESULTS-RESULTS
pseudostubs.dll dlopen: Win32 error 126
foo.dll ok
psuedostubs.dll ok

reid


> -Original Message-
> From: Reid Thompson 
> Sent: Tuesday, August 10, 2004 3:49 PM
> To: Peter Ekberg; [EMAIL PROTECTED]
> Subject: RE: Dynamic loading of cygwin dependent dlls
> 
> 
> take the underscore out of the dll name
> 
> psuedo_stub -> psuedostub
> 
> reid
> 
> 
> > -Original Message-
> > From: Peter Ekberg [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 10, 2004 3:11 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Dynamic loading of cygwin dependent dlls
> > 
> > 
> > Christopher Faylor wrote:
> > >On Thu, Aug 05, 2004 at 09:09:40AM +0200, Peter Ekberg wrote:
> > >>I have read several messages stating that dlopen does not work for
> > dlls
> > >>that depend on cygwin1.dll.
> > >>(e.g. http://sources.redhat.com/ml/cygwin/2004-06/msg01056.html).
> > >>I have also understood that this is due to some structures
> > not being
> > >>initialized in that case.
> > >>
> > >>Is this dlopen problem limited to non-cygwin apps? I.e. is it true
> > >>that an app that depends directly on the cygwin1.dll is 
> > incapable of
> > >>dlopening dlls that depend on cygwin1.dll?
> > >
> > >No, it is not true.  dlopen would be pretty worthless if it
> > didn't work
> > >in a standard cygwin program.
> > 
> > Indeed. Knowing that it should work, I was inspired to do
> > some more tests.
> > 
> > The reason I asked is that the following results in a dll
> > that can't be
> > dlopened:
> > 
> > foo.c:
> > 8<---
> > __declspec(dllexport) int foo(int bar);
> > 
> > int foo(int bar)
> > {
> > return bar;
> > }
> > 8<---
> > 
> > Build commands:
> > $ gcc -c foo.c
> > $ dlltool --dllname pseudo_stubs.dll --exclude-symbols
> > [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
> ,DllMainCR
> > [EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
> > $ dllwrap --dllname pseudo_stubs.dll --output-lib
> > pseudo_stubs.dll.a --def foo.def foo.o -L/usr/lib
> > 
> > However, further tests have shown that if I change the name
> > pseudo_stubs to foo in the above commands, it works like a 
> > charm. Like this:
> > 
> > $ gcc -c foo.c
> > $ dlltool --dllname foo.dll --exclude-symbols
> > [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
> ,DllMainCR
> > [EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
> > $ dllwrap --dllname foo.dll --output-lib foo.dll.a --def
> > foo.def foo.o -L/usr/lib
> > 
> > I use this program to test whether the resulting dll works:
> > 
> > load.c
> > 8<---
> > #include 
> > #include 
> > 
> > char *dlls[] = {
> > "pseudo_stubs.dll",
> > "foo.dll",
> > NULL
> > };
> > 
> > int main(void)
> > { 
> > int i;
> > void *res;
> > 
> > for(i=0; dlls[i]; ++i) {
> > printf("%s\t", dlls[i]);
> > res=dlopen(dlls[i], RTLD_LAZY | RTLD_GLOBAL);
> > if(!res)
> > printf("%s\n", dlerror());
> > else
> > printf("ok\n");
> > }
> > 
> > return 0;
> > }
> > 8<---
> > 
> > I build load.c with "gcc load.c -o load" and ./load produces this
> > output:
> > pseudo_stubs.dlldlopen: Win32 error 998
> > foo.dll ok
> > 
> > Any help on this would be appreciated.
> > 
> > Cheers,
> > Peter Ekberg
> > 
> > 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:   http://cygwin.com/problems.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 
> 

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

RE: Dynamic loading of cygwin dependent dlls

[Reid Thompson]

DOH!
> char *dlls[] = {
>   "pseudostubs.dll",
>   "foo.dll",
>   "psuedostubs.dll",
>   NULL
> };
should be
> char *dlls[] = {
>   "psuedostubs.dll",
>   "foo.dll",
>   "psuedostubs.dll",
>   NULL
> };

and all works

reid


> -Original Message-
> From: Reid Thompson 
> Sent: Tuesday, August 10, 2004 3:57 PM
> To: Reid Thompson; Peter Ekberg; [EMAIL PROTECTED]
> Subject: RE: Dynamic loading of cygwin dependent dlls
> 
> 
> actually -- that's not it, as this code, gives the following results:
> 
> CODE---CODE
> #include 
> #include 
> 
> char *dlls[] = {
>   "pseudostubs.dll",
>   "foo.dll",
>   "psuedostubs.dll",
>   NULL
> };
> 
> int main(void)
> { 
>   int i;
>   void *res;
>   
>   for(i=0; dlls[i]; ++i) {
>   printf("%s\t", dlls[i]);
>   res=dlopen(dlls[i], RTLD_LAZY | RTLD_GLOBAL);
>   if(!res)
>   printf("%s\n", dlerror());
>   else
>   printf("ok\n");
>   }
> 
>   return 0;
> }
> RESULTS-RESULTS
> pseudostubs.dll dlopen: Win32 error 126
> foo.dll ok
> psuedostubs.dll ok
> 
> reid
> 
> 
> > -Original Message-
> > From: Reid Thompson
> > Sent: Tuesday, August 10, 2004 3:49 PM
> > To: Peter Ekberg; [EMAIL PROTECTED]
> > Subject: RE: Dynamic loading of cygwin dependent dlls
> > 
> > 
> > take the underscore out of the dll name
> > 
> > psuedo_stub -> psuedostub
> > 
> > reid
> > 
> > 
> > > -Original Message-
> > > From: Peter Ekberg [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, August 10, 2004 3:11 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Dynamic loading of cygwin dependent dlls
> > > 
> > > 
> > > Christopher Faylor wrote:
> > > >On Thu, Aug 05, 2004 at 09:09:40AM +0200, Peter Ekberg wrote:
> > > >>I have read several messages stating that dlopen does 
> not work for
> > > dlls
> > > >>that depend on cygwin1.dll.
> > > >>(e.g. 
> http://sources.redhat.com/ml/cygwin/2004-06/msg01056.html).
> > > >>I have also understood that this is due to some structures
> > > not being
> > > >>initialized in that case.
> > > >>
> > > >>Is this dlopen problem limited to non-cygwin apps? I.e. 
> is it true 
> > > >>that an app that depends directly on the cygwin1.dll is
> > > incapable of
> > > >>dlopening dlls that depend on cygwin1.dll?
> > > >
> > > >No, it is not true.  dlopen would be pretty worthless if it
> > > didn't work
> > > >in a standard cygwin program.
> > > 
> > > Indeed. Knowing that it should work, I was inspired to do 
> some more 
> > > tests.
> > > 
> > > The reason I asked is that the following results in a dll 
> that can't 
> > > be
> > > dlopened:
> > > 
> > > foo.c:
> > > 8<---
> > > __declspec(dllexport) int foo(int bar);
> > > 
> > > int foo(int bar)
> > > {
> > >   return bar;
> > > }
> > > 8<---
> > > 
> > > Build commands:
> > > $ gcc -c foo.c
> > > $ dlltool --dllname pseudo_stubs.dll --exclude-symbols 
> > > [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
> > ,DllMainCR
> > > [EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
> > > $ dllwrap --dllname pseudo_stubs.dll --output-lib 
> pseudo_stubs.dll.a 
> > > --def foo.def foo.o -L/usr/lib
> > > 
> > > However, further tests have shown that if I change the name 
> > > pseudo_stubs to foo in the above commands, it works like a charm. 
> > > Like this:
> > > 
> > > $ gcc -c foo.c
> > > $ dlltool --dllname foo.dll --exclude-symbols 
> > > [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]
> > ,DllMainCR
> > > [EMAIL PROTECTED],[EMAIL PROTECTED] --output-def foo.def  foo.o
> > > $ dllwrap --dllname foo.dll --output-lib foo.dll.a --def foo.def 
> > > foo.o -L/usr/lib
> > > 
> > > I use this program to test whether the resulting dll works:
> > > 
> > > load.c
> > > 8<---
> > > #include 
> > > #include 
> > > 
> > > char *dlls[] = {
> > >   "pseudo_stubs.dll",
> > >   "foo.dll",
> > >   NULL
> > > };
> > > 
> > > int main(void)
> > > { 
> > >   int i;
> > >   void *res;
> > >   
> > >   for(i=0; dlls[i]; ++i) {
> > >   printf("%s\t", dlls[i]);
> > >   res=dlopen(dlls[i], RTLD_LAZY | RTLD_GLOBAL);
> > >   if(!res)
> > >   printf("%s\n", dlerror());
> > >   else
> > >   printf("ok\n");
> > >   }
> > > 
> > >   return 0;
> > > }
> > > 8<---
> > > 
> > > I build load.c with "gcc load.c -o load" and ./load produces this
> > > output:
> > > pseudo_stubs.dll  dlopen: Win32 error 998
> > > foo.dll   ok
> > > 
> > > Any help on this would be appreciated.
> > > 
> > > Cheers,
> > > Peter Ekberg
> > > 
> > > 
> > 
> > --
> > Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> > Problem reports:   http://cygwin.com/problems.html
> > Documentation: http://cygwin.com/docs.html
> > FAQ:   http://cygwin.com/faq/
> > 
> >

RE: Dynamic loading of cygwin dependent dlls

[Reid Thompson]

well -- i just redid the entire thing, with the correct spelling and
your original post works

$ ./load
pseudo_stub.dll ok
foo.dll ok

reid


> -Original Message-
> From: Peter Ekberg [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 10, 2004 4:06 PM
> To: Reid Thompson; [EMAIL PROTECTED]
> Subject: RE: Dynamic loading of cygwin dependent dlls
> 
> 
> Reid Thompson wrote:
> > take the underscore out of the dll name
> > 
> > psuedo_stub -> psuedostub
> 
> Yes, that works. It also works if I add an s making it 
> pseudo_stubss, so the underscore is not it.
> 
> Or is it? Are underscores really not allowed in dll names?
> 
> BTW, here is the correct spelling of pseudo.
> 
> Cheers,
> Peter
> 

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

RE: Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

 

Reid Thompson wrote:
> well -- i just redid the entire thing, with the correct spelling and
> your original post works
> 
> $ ./load
> pseudo_stub.dll ok
> foo.dll ok

That's strange, did my original post first get you error 998 for
pseudo_stubs.dll and now, after some juggling, the same thing is ok?

Cheers,
Peter

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

RE: Dynamic loading of cygwin dependent dlls

[Peter Ekberg]

I wrote:
> Reid Thompson wrote:
> > well -- i just redid the entire thing, with the correct spelling and
> > your original post works
> > 
> > $ ./load
> > pseudo_stub.dll ok
> > foo.dll ok
> 
> That's strange, did my original post first get you error 998 for
> pseudo_stubs.dll and now, after some juggling, the same thing is ok?

Ah, now I see it. You have to be careful with your typing.
pseudo_stubs.dll (with one s in the end) is the name that fails.
Apparently both pseudo_stub.dll (no s) and psuedo_stubs.dll (bad
spelling) work. And pseudo_stubss.dll (double s) definitely works, that
I have tried myself.

Cheers,
Peter


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

Re: Dynamic loading of cygwin dependent dlls

[Gerrit P. Haase]

Hallo Peter,

Am Dienstag, 10. August 2004 um 22:58 schriebst du:

> I wrote:
>> Reid Thompson wrote:
>> > well -- i just redid the entire thing, with the correct spelling and
>> > your original post works
>> > 
>> > $ ./load
>> > pseudo_stub.dll ok
>> > foo.dll ok
>> 
>> That's strange, did my original post first get you error 998 for
>> pseudo_stubs.dll and now, after some juggling, the same thing is ok?

> Ah, now I see it. You have to be careful with your typing.
> pseudo_stubs.dll (with one s in the end) is the name that fails.
> Apparently both pseudo_stub.dll (no s) and psuedo_stubs.dll (bad
> spelling) work. And pseudo_stubss.dll (double s) definitely works, that
> I have tried myself.

You have checked what error 998 actually is?

#define ERROR_NOACCESS 998L

I cannot believe that it depends on the name of a DLL whether it can
be dlopened or not.  There must be another error with your test!

Consider this (with source from your first posting):
$ gcc -shared -o pseudo_stubs.dll foo.c
$ gcc -o load load.c
$ ./load
pseudo_stubs.dllok
foo.dll dlopen: Win32 error 126
$ cp pseudo_stubs.dll foo.dll
$ ./load
pseudo_stubs.dllok
foo.dll ok


Gerrit
-- 
=^..^=



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

Re: ImageMagick

[Gerrit P. Haase]

Colin writes:

> I'm getting a problem with ImageMagick 6.0.3-1

The maintainer is busy, please be patient.

[...]

> I really, really, need to get this to work!!

Recompile yourself?
Downgrade?

> although its offtopic, if anyone knows of another way of converting a X
> bitmap (.xbm) to an .eps file for inclusion in a LaTeX document I'd be most
> most grateful. The native win32 ImageMagick does not seem to work; it
> creates a dodgy .eps file that nothing can read, including itself.

There is always a Cygwin version available at the IM website, go
figure:
http://www.imagemagick.net/download/binaries/ImageMagick-i686-pc-cygwin.tar.gz 

Gerrit
-- 
=^..^=



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

Problem linking cygwin dll with MSVC application

[Mirko]

Hello,
(this is a repeat post, as I have not seen the first one on the list)
I am trying to link a numerical routine written in Fortran to a data 
analysis application running on MS Windows 2000(IDL from RSI -- see 
www.rsinc.com).  IDL is compiled using MS' visual C compiler.

IDL has provisions to link external routines to it.  In essence, I have 
to generate a dll, and provide IDL with 1) the dll name and 2) entry 
point into the dll (i.e. a symbol for the subroutine that IDL will be 
calling).

I've been using gcc on cygwin with the following command in order for my 
dll to use MS' and not Cygwin's dll:

g77 -share -fPIC -mno-cygwin ...
If I compile and link with Cygwin's dll (don't use the -mno-cygwin 
option), I'll get IDL to crash all the time.  I guess that is because of 
some conflicts between Cygwin's and MS dll's.

Using -mno-cygwin works for some cases and not others (i.e, causes IDL 
to not to crash or crash.  Basically, if I pass the routine a vector of 
values, it will cause IDL to crash and conversely, if I pass it a 
scalar, it will run fine and return to IDL.

(No, this has nothing to do with incompatibility with declared variables 
in the routine.  Instead, if I am passing a vector, I call one interface 
Fortran routine with a Do loop over the individual values in the vector, 
and if I am passing a scalar, I am calling a different interface routine.)

My question is: are there other switches or options that I need to use 
so as not to cause conflicts between Cygwin compiled dll's and MS 
utilitites?

I understand that I may be mis-using Cygwin.  I am thus considering to 
do the compilation and dll creation using MinGW, because, as I 
understand it, that package is meant for program development on the MS 
platform.  However, I am not certain as how to  create a DLL in MinGW 
that is compatible with software compiled with MS' compiler.  I posted a 
such a question on the MinGW list.

Any suggestions or pointers to documentation?
Thanks,
Mirko
--
*m*irko*vukovic*-at-*nycap*ital-*r*oad*r*unner-com
--
*m*irko*vukovic*-at-nycap-rr-com
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Problem linking cygwin dll with MSVC application

[Christopher Faylor]

On Mon, Aug 09, 2004 at 09:22:01PM -0400, Mirko wrote:
>I understand that I may be mis-using Cygwin.  I am thus considering to 
>do the compilation and dll creation using MinGW, because, as I 
>understand it, that package is meant for program development on the MS 
>platform.  However, I am not certain as how to  create a DLL in MinGW 
>that is compatible with software compiled with MS' compiler.  I posted a 
>such a question on the MinGW list.
>
>Any suggestions or pointers to documentation?

If you don't need the UNIX-like utilities of cygwin, then you definitely
should be using MinGW for your efforts.  There really is very little
difference between building dlls using MinGW and Cygwin.

And, of course, MinGW questions belong on the mingw mailing list, as you
know.

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

RESOLVED (?): Cygwin permissions problem

[Fish]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(Ref: original "Cygwin permissions problem" and related threads)

FYI: I managed to resolve my issue by completely re-installing Cygwin
from scratch after having added (and allowing to propagate) the
"Everyone" group (Read and Execute only) to my set of permissions
[for all of my partitions].

What I find odd(?) about this whole episode is that the "Everyone"
group should apparently be required [by Cygwin] like that. Could
someone explain that to me?

The reason I personally find it to be somewhat "odd" is simply
because my Windows system behaves perfectly (just fine) without it.

Now I know that Cygwin (i.e. *nix) is NOT Windows and vice versa, but
why does Cygwin (*nix?) apparently choke whenever none of the (its?)
files are given any type of "public" access? (Which is what the
"Everyone" group is for, yes?)

It seems to me one *should* be able to do what I was doing (i.e. only
assigning explicit "private" (i.e. no public) permissions/access to
all of my files/folders) without any serious side effects, but
apparently not.

Could some kind soul out there help me to understand why *SOME* type
of "public" permissions set is [apparently] required by Cygwin?
(*nix?)

Thanks.

- -- 
"Fish" (David B. Trout)
   [EMAIL PROTECTED]

Fight Spam! Join CAUCE!
http://www.cauce.org/

-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBQRmCH0j11/TE7j4qEQLOdgCgoCK23ryFYDroeJp2+s2UKpxjaFEAnjw/
hN0FHEwvNjIuCd8fnQNT2zmh
=HGSo
-END PGP SIGNATURE-



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

Re: RESOLVED (?): Cygwin permissions problem

[Larry Hall]

At 10:19 PM 8/10/2004, you wrote:
> 
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>(Ref: original "Cygwin permissions problem" and related threads)
>
>FYI: I managed to resolve my issue by completely re-installing Cygwin
>from scratch after having added (and allowing to propagate) the
>"Everyone" group (Read and Execute only) to my set of permissions
>[for all of my partitions].
>
>What I find odd(?) about this whole episode is that the "Everyone"
>group should apparently be required [by Cygwin] like that. Could
>someone explain that to me?
>
>The reason I personally find it to be somewhat "odd" is simply
>because my Windows system behaves perfectly (just fine) without it.
>
>Now I know that Cygwin (i.e. *nix) is NOT Windows and vice versa, but
>why does Cygwin (*nix?) apparently choke whenever none of the (its?)
>files are given any type of "public" access? (Which is what the
>"Everyone" group is for, yes?)
>
>It seems to me one *should* be able to do what I was doing (i.e. only
>assigning explicit "private" (i.e. no public) permissions/access to
>all of my files/folders) without any serious side effects, but
>apparently not.
>
>Could some kind soul out there help me to understand why *SOME* type
>of "public" permissions set is [apparently] required by Cygwin?
>(*nix?)
>
>Thanks.


I thought Pierre did a rather good (good?  I mean excellent! ;-) ) job
of explaining the issue with his last email to you on this subject:



The key part is that 'setup.exe' is not a Cygwin program (it can't be) 
so it's largely bound by Windows security semantics.  These don't map 
well into the Cygwin emulation of POSIX permissions.  So, if neither 
you, nor standard groups, nor "Everyone" owns the file, there will be 
a mismatch of the permissions on the files and directories in the 
Windows view (ACLs) and the POSIX view (owner, group, world).  As 
Pierre pointed out, POSIX tools like 'cp' only operate on POSIX 
permissions.  If those are '-', then you get no permissions
on that copied file.  So one solution is to do what you did.  Make 
sure that 'Everyone' owns the files in the Windows ACL.  You do that
by creating the directory you want to install Cygwin to and setting
the permissions, via Windows, before Cygwin installation, making sure
to set the permissions so they are inherited.  For the case of 'Everyone',
that maps to the 'world'.  Another alternative is to create a CYGWIN
environment variable with 'nontsec' set before installation.  That will
make Cygwin use Windows ACLs, following those rules exclusively.

If you're still having trouble understanding what's going on here, I
suggest you read the NT security chapter of the User's Guide:



If you read it already, read it again.  I'm serious.  This is complicated
stuff giving the partial mapping of ACLs to POSIX permissions.  It takes
some real thought to understand it all and it's limitations.  Reading this
more than once can make things click where they didn't before.  When you
get so you understand it, feel free to offer patches to make Cygwin and 
'setup.exe' better in this area.  You can save the next person who has
tight permissions some trouble. :-)


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


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

[ANNOUNCEMENT] New package: ORBit2(-devel)-2.10.3-1

[Yaakov Selkowitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The following packages have been added to the Cygwin distribution:

*** ORBit2-2.10.3-1
*** ORBit2-devel-2.10.3-1

This is one of the core GNOME backend libraries, and a prerequisite to
libbonobo.

ORBit2 is a CORBA 2.4-compliant Object Request Broker (ORB)
featuring mature C and Perl bindings.  It supports POA, DII, DSI,
TypeCode, Any, IR and IIOP.  Optional features including INS and
threading are available. ORBit2 is engineered for the GNU Object Model
Environment (GNOME) with a focus on performance, low resource usage,
and security.

Yaakov


~  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBGYxdpiWmPGlmQSMRAk0LAKC717LyuEGJ+TkOPTFxTgLDf179EgCeO8tP
7NBARRhtTLfsFranOM2qjQ8=
=ibeL
-END PGP SIGNATURE-


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

Re: Re: ssh password

[fishing]

please delete my email address from mail list.thanks!

=== 2004-05-06 21:27:53 您在来信中写道：===

>On Thu, 6 May 2004, David Corbin wrote:
>
>> I'm very confused.  When ssh to cygwin sshd, how does it try to match the
>> password?
>
>It doesn't.  It delegates to Windows.
>   Igor
>-- 
>   http://cs.nyu.edu/~pechtcha/
>  |\  _,,,---,,_   [EMAIL PROTECTED]
>ZZZzz /,`.-'`'-.  ;-;;,_   [EMAIL PROTECTED]
> |,4-  ) )-,_. ,\ (  `'-'  Igor Pechtchanski, Ph.D.
>'---''(_/--'  `-'\_) fLa.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
>
>"I have since come to realize that being between your mentor and his route
>to the bathroom is a major career booster."  -- Patrick Naughton
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Problem reports:   http://cygwin.com/problems.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/
>
>

= = = = = = = = = = = = = = = = = = = =


致
礼！
 
 
fishing
[EMAIL PROTECTED]
　　2004-08-11