https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=8bbb3d3a23e4d3ab8e707168f1c6bd7b0e19f6df
commit 8bbb3d3a23e4d3ab8e707168f1c6bd7b0e19f6df
Author: Michael Haubenwallner
Date: Thu Jan 12 10:03:52 2017 +0100
forkables: use dynloaded dll's IndexNumber as dirname
Diff:
---
winsup
Hi Michael,
On Mar 1 20:18, Michael Haubenwallner wrote:
> Hi Corinna,
>
> On 02/23/2017 03:03 PM, Corinna Vinschen wrote:
> > Hi Michael,
> >
> > I'm inclined to promote the "forkables" code to master. I just have a
> > few points before we do that:
> >
> > - Revert bumping of
Hi Corinna,
On 02/23/2017 03:03 PM, Corinna Vinschen wrote:
> Hi Michael,
>
> I'm inclined to promote the "forkables" code to master. I just have a
> few points before we do that:
>
> - Revert bumping of CYGWIN_VERSION_SHARED_DATA. We only have to do that
> if the shared region changes in
Hi Michael,
I'm inclined to promote the "forkables" code to master. I just have a
few points before we do that:
- Revert bumping of CYGWIN_VERSION_SHARED_DATA. We only have to do that
if the shared region changes in an incompatible way. But this is just
adding a member to the end.
- I'm
On Feb 10 15:08, Michael Haubenwallner wrote:
> Hi Corinna,
>
> as realized during write of tl;dr draft for the topic/forkables branch,
> >
> >
> > * The temporary subdirectory name for a dynamically loaded dll is formed
> >using the original directory's NTFS-IndexNumber.
> >
> >
benwallner <michael.haubenwall...@ssi-schaefer.com>
Date: Thu, 12 Jan 2017 10:03:52 +0100
Subject: [PATCH] forkables: use dynloaded dll's IndexNumber as dirname
---
winsup/cygwin/forkable.cc | 33 -
1 file changed, 8 insertions(+), 25 deletions(-)
diff --git
by the DLL's not being
in the expected place. They were in /usr/bin and this is not in the search path
for the DynaLoader so it doesn't load the library.
Hopefully have this fixed now.
Cheers,
Mark.
On 04/09/2012, at 11:27 AM, Yaakov (Cygwin/X) wrote:
http://cygwin.com/acronyms/#PCYMTWLL !
On Tue
On Tue, 2012-09-04 at 16:55 +1000, Mark O'Keefe wrote:
I don't have link errors, I have perl runtime errors when trying to execute
the
bootstrap of the C code for the modules. This is caused by the DLL's not
being
in the expected place. They were in /usr/bin and this is not in the search
by the DLL's not
being
in the expected place. They were in /usr/bin and this is not in the search
path
for the DynaLoader so it doesn't load the library.
Which, since it sounds as this is an autotools-driven package, would be
caused by a missing -module flag in the corresponding *_la_LDFLAGS
Hi,
I'm trying to use cygport to package up DLL's that are used as part of a set of
perl packages. The place that these are meant to be installed is under the
perl site configuration
(/usr/lib/perl5/site_perl/version/auto/package/subpackage/*.dll.
Currently what happens is libtool munges
http://cygwin.com/acronyms/#PCYMTWLL !
On Tue, 2012-09-04 at 10:21 +1000, Mark O'Keefe wrote:
I'm trying to use cygport to package up DLL's that are used as part
of a set of perl packages.
Being vague doesn't help us help you. Telling us what package you're
trying to build, and attaching
bother for the reasons I explained. (The Win32 version is
named R.dll.)
Specially as the dll's are on a dedicate directory, out of the PATH
usr/lib/R/lib/libR.dll
usr/lib/R/lib/libRblas.dll
usr/lib/R/lib/libRlapack.dll
You'll see that my patches move these into /usr
On 2/8/2012 9:14 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2012-02-08 at 23:51 +0100, marco atzeri wrote:
curiosity, any reason why the tcl/tk dll's are
not using the cyg prefix ?
In fact, there is. The point of the cyg prefix is to avoid possible
mismatches with MinGW DLLs using the lib
Hi Yaakov,
curiosity, any reason why the tcl/tk dll's are
not using the cyg prefix ?
/usr/bin/libtcl8.5.dll
/usr/bin/libtk8.5.dll
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com
On Wed, 2012-02-08 at 23:51 +0100, marco atzeri wrote:
curiosity, any reason why the tcl/tk dll's are
not using the cyg prefix ?
In fact, there is. The point of the cyg prefix is to avoid possible
mismatches with MinGW DLLs using the lib prefix. In this case,
however, forcing a cyg prefix
On 2/9/2012 3:14 AM, Yaakov (Cygwin/X) wrote:
On Wed, 2012-02-08 at 23:51 +0100, marco atzeri wrote:
curiosity, any reason why the tcl/tk dll's are
not using the cyg prefix ?
In fact, there is. The point of the cyg prefix is to avoid possible
mismatches with MinGW DLLs using the lib prefix
On Wed, May 26, 2010 at 03:39, Kaylan wrote:
OS: Windows 7
cygwin installation: Basic C/C++ compilation,debug,link,make,ect
I have searched all over for answers and have came up with nothing. When i
compile a C program i now know i need to include some .dll's with the .exe
in order
OS: Windows 7
cygwin installation: Basic C/C++ compilation,debug,link,make,ect
I have searched all over for answers and have came up with nothing. When
i compile a C program i now know i need to include some .dll's with the
.exe in order for it to run on a remote machine. At least thats been
2010/2/21 Christopher Faylor:
On Sun, Feb 21, 2010 at 02:47:35PM +0100, Reini Urban wrote:
For cygwin perl powerusers like me the attached script perlrebase.sh
might come handy.
Hey, nice idea. Should this go in the distro somewhere?
I'm not sure yet. If so I'll add it to perl.
We need an
For cygwin perl powerusers like me the attached script perlrebase.sh
might come handy.
perlrebase.sh 5.11.4
searches for the perl5.11.4 executable in /usr/local/bin and /usr/bin
then rebases all corresponding dll's.
default is 5.10.1
--
Reini Urban
#!/bin/sh
suff=$1
suff=${suff:=5.10.1
On Sun, Feb 21, 2010 at 02:47:35PM +0100, Reini Urban wrote:
For cygwin perl powerusers like me the attached script perlrebase.sh
might come handy.
Hey, nice idea. Should this go in the distro somewhere?
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ:
to
make setup work are only part of setup. No changes to
cygwin's internals are needed.
I saw a msg. about deleting runtime libraries from a running
process like bash. I believe this was meant to show that cygwin
simulates POSIX correctness in fork by manually copying and
reloading DLL's from the pre
DLL's from the pre-forked process to the post-fork process's
address space. It does this by reloading DLL's from their
original filenames at the time of fork. This suffers from the
race-condition that if the original DLL's change (or in this
case, are updated), then the post-forked copy
Hi Folks,
I'm looking for the instructions (I've searched with Google etc.) about
how to compile the Cygwin DLL's from source using non-Microsoft
compilers, e.g. those included with a functional Cygwin system.
Is this possible, or do the DLL's have to be built using either free or
low cost
On Thu, 26 Jan 2006, Keith Christian wrote:
I'm looking for the instructions (I've searched with Google etc.) about
how to compile the Cygwin DLL's from source using non-Microsoft
compilers, e.g. those included with a functional Cygwin system.
Did you try the FAQ?
http://cygwin.com/faq
Igor Peshansky wrote:
Did you try the FAQ?
http://cygwin.com/faq/faq.programming.html#faq.programming.building-cygwin
Didn't try the FAQ because I didn't run across it with searches but I'll
take a look, thanks.
It would be interesting to find out where you got the idea that Cygwin
needs a
On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote:
On 10/27/05, Alan Hourihane wrote:
Yep, uploading myself to sourceware now.
They'll be in-place in the next hour.
Alan,
I've taken the opportunity to evaluate the new package. Prior
versions of Cygwin/Xorg provided the dlls
On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote:
I've taken the opportunity to evaluate the new package. Prior
versions of Cygwin/Xorg provided the dlls and development files for
the libDPS interface. For some reason, they were omitted in this
release. I've been hunting through
On 10/28/05, Alan Hourihane wrote:
This test version was built from the mainline X.Org trunk code and not
the CYGWIN branch.
I'll be working on getting whatever changes exist on that branch over
into the mainline trunk code next.
If the patches are still in CYGWIN then that's the problem.
On 10/28/05, Alexander Gottwald wrote:
On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote:
I've taken the opportunity to evaluate the new package. Prior
versions of Cygwin/Xorg provided the dlls and development files for
the libDPS interface. For some reason, they were omitted in
On 10/28/05, Nicholas Wourms wrote:
On 10/28/05, Alexander Gottwald wrote:
On Thu, 2005-10-27 at 19:56 -0400, Nicholas Wourms wrote:
I've taken the opportunity to evaluate the new package. Prior
versions of Cygwin/Xorg provided the dlls and development files for
the libDPS
On 10/27/05, Alan Hourihane wrote:
Yep, uploading myself to sourceware now.
They'll be in-place in the next hour.
Alan,
I've taken the opportunity to evaluate the new package. Prior
versions of Cygwin/Xorg provided the dlls and development files for
the libDPS interface. For some reason,
I have just installed the X components of Cygwin and am hoping to
eventually connect with XDMCP to my Linux machine. But I'm having some
serious teething problems.
First, XWin seems to be having difficulty finding the dlls. If I run
XWin -query [computer name] I First I get an error message
On Thu, 7 Jul 2005, Angus Veitch wrote:
First, XWin seems to be having difficulty finding the dlls. If I run
XWin -query [computer name] I First I get an error message saying that
it can't find cygwin1.dll. If I copy that dll file from the cygwin\bin\
directory into
On Thu, 7 Jul 2005, Angus Veitch wrote:
I have just installed the X components of Cygwin and am hoping to
eventually connect with XDMCP to my Linux machine. But I'm having some
serious teething problems.
First, XWin seems to be having difficulty finding the dlls. If I run
XWin -query
Hi,
The way symbol names are built in dll differs if they are related to c
call convention or to c++ call, and that could be your problem. When
compiling hello.c with gcc, your exported symbol corresponds to C
calling convention.
When compiling dll with g++, you should declare your exported
On Sun, Jan 16, 2005 at 08:43:44PM -0500, Pierre A. Humblet wrote:
On Sun, Jan 16, 2005 at 02:56:57PM -0800, linda w wrote:
I was told I might fix the problem of typing in a partial command name
like cyg, and the command completion character and getting a long list
of DLL's with a few EXE's
and getting a long list
of DLL's with a few EXE's thrown in.
I had been told it could be fixed through adjustment of the bash command
completion or in the readline completion used by bash. This doesn't
appear to be a straight forward solution.
Have you looked into it? It's easy in bash
completion character and getting a long list
of DLL's with a few EXE's thrown in.
I had been told it could be fixed through adjustment of the bash command
completion or in the readline completion used by bash. This doesn't
appear to be a straight forward solution.
Have you looked into it? It's easy
I've been trying to build a DLL using g++, and given the problems I was
having, I decided to try a 'toy' example, which is available at:
http://cygwin.com/cygwin-ug-net/dll.html
I tweaked the two files around thusly:
hello.C:
-
#include stdio.h
int hello() { printf(Hello World\n);}
. As a backup, a flag in the CYGWIN env var
could specify the old behavior to peek inside every file to determine if
it was an executable, and a 2nd flag, LIBS_EXEC (?), could be used
to include libraries as executable commands.
Marking .dll's, ocx's, etc as commands under POSIX doesn't seem
particularly
Max Bowsher wrote:
linda w wrote:
Is there some reason cygwin needs to return DLL's as executables, as the
underlying OS doesn't require it (having no 'executable bit').
Wrong, actually the underlying OS *does* require it. It may not have
mode bits, but it does have ACLs.
Before calling me wrong
linda w wrote:
More to the point, what would break in the cygwin environment,
Try to chmod 644 any dll and call a program that uses this dll.
This fails for me (on NT4 with NTFS), if it succeeds for you, fine.
Change the permissions as you like it;)
Gerrit
--
=^..^=
--
Unsubscribe info:
On Mon, Jan 17, 2005 at 12:38:51AM +0100, Gerrit P. Haase wrote:
More to the point, what would break in the cygwin environment,
Try to chmod 644 any dll and call a program that uses this dll. This
fails for me (on NT4 with NTFS), if it succeeds for you, fine. Change
the permissions as you like
On Sun, Jan 16, 2005 at 02:56:57PM -0800, linda w wrote:
I was told I might fix the problem of typing in a partial command name
like cyg, and the command completion character and getting a long list
of DLL's with a few EXE's thrown in.
I had been told it could be fixed through adjustment
On Sun, Jan 16, 2005 at 08:13:43PM -0500, Christopher Faylor wrote:
On Mon, Jan 17, 2005 at 12:38:51AM +0100, Gerrit P. Haase wrote:
More to the point, what would break in the cygwin environment,
Try to chmod 644 any dll and call a program that uses this dll. This
fails for me (on NT4 with
On Sun, 16 Jan 2005, Yitzchak Scott-Thoennes wrote:
On Sun, Jan 16, 2005 at 08:13:43PM -0500, Christopher Faylor wrote:
On Mon, Jan 17, 2005 at 12:38:51AM +0100, Gerrit P. Haase wrote:
More to the point, what would break in the cygwin environment,
Try to chmod 644 any dll and call a
linda w wrote:
Is there some reason cygwin needs to return DLL's as executables, as the
underlying OS doesn't require it (having no 'executable bit').
Wrong, actually the underlying OS *does* require it. It may not have mode
bits, but it does have ACLs.
Max.
--
Unsubscribe info: http
I was told I might fix the problem of typing in a partial command name
like cyg, and the command completion character and getting a long list
of DLL's with a few EXE's thrown in.
I had been told it could be fixed through adjustment of the bash command
completion or in the readline completion
Hello!
I am compiling stuff on cygwin but with -mno-cygwin
to make the produced software independent of cygwin itself.
The DLL's that you can download from the setup of cygwin
are all dependent of cygwin1.dll?
I would like to use for example lcms that you can install
directly over the network
On Fri, Jan 14, 2005 at 03:15:32PM +0100, Barthel, Mattias wrote:
I am compiling stuff on cygwin but with -mno-cygwin to make the
produced software independent of cygwin itself.
The DLL's that you can download from the setup of cygwin are all
dependent of cygwin1.dll?
Of course!
I would like
Barthel, Mattias wrote:
Hello!
I am compiling stuff on cygwin but with -mno-cygwin
to make the produced software independent of cygwin itself.
The DLL's that you can download from the setup of cygwin
are all dependent of cygwin1.dll?
There are two packages containing no-cygwin DLLs, mingw-zlib
Just had the problem and though I would post so that others know the
workaround / fix if they have it as well.
If you have installed perl modules from CPAN or other source its likely
that the perl.lst.gz hasn't been updated with the additional dll's hence
rebaseall doesn't remap them and the issue
Steve,
On Wed, Nov 24, 2004 at 01:20:08PM -, Steven Hartland wrote:
Just had the problem and though I would post so that others know the
workaround / fix if they have it as well.
[snip]
Hope this helps people
I recommend using rebaseall's -T option instead:
when I moved
Yaakov cygclamav-1.dll into my PATH, and even if I call the programs with
Yaakov - --help or --version options. What's going on now??
It happened to me too sometimes. Check the permissions on the dll's
sometimes they do not have the execute permission. Don't know why so
Oliver schrieb:
Secondly, the resultant DLL will be linkable from a VC++ program, but the
C++ functions in it will not be accessible from code compiled with VC++.
Of course, the usual c++ name mangling incompatibilities.
And there comes the .def file to help.
You can define your needed aliases
Hi folks, I'm confused about the files that dllwrap
creates. On Unix (where I've been programming forever) all you
have to do is create a .so shared library. But dllwrap ends up
creating a .a file, a .def file, and a .dll file, yet I can
build a program that links to, e.g., mylib.dll, with
On Fri, 27 Aug 2004, Oliver wrote:
Hi folks, I'm confused about the files that dllwrap
creates. On Unix (where I've been programming forever) all you
have to do is create a .so shared library. But dllwrap ends up
creating a .a file, a .def file, and a .dll file, yet I can
build a program
On Fri, 27 Aug 2004, Igor Pechtchanski wrote:
On Fri, 27 Aug 2004, Oliver wrote:
Hi folks, I'm confused about the files that dllwrap
creates. On Unix (where I've been programming forever) all you
have to do is create a .so shared library. But dllwrap ends up
creating a .a file, a .def
Igor Pechtchanski pechtcha at cs.nyu.edu writes:
On Fri, 27 Aug 2004, Oliver wrote:
creating a .a file, a .def file, and a .dll file, yet I can
build a program that links to, e.g., mylib.dll, with only -L. -lmylib,
*wihtout* having the .def or .a available. So where and when are the .a
Igor Pechtchanski pechtcha at cs.nyu.edu writes:
The newer versions of gcc apparently allow you to link directly to a .dll
file. The .def and .a are needed for older versions of gcc, and possibly
for some other tools.
[...]
The reason you want an 'extern C' for DLL functions in general
On Fri, 27 Aug 2004, Oliver wrote:
Igor Pechtchanski pechtcha at cs.nyu.edu writes:
The newer versions of gcc apparently allow you to link directly to a .dll
file. The .def and .a are needed for older versions of gcc, and possibly
for some other tools.
[...]
The reason you want
Secondly, the resultant DLL will be linkable from a VC++ program, but the
C++ functions in it will not be accessible from code compiled with VC++.
Of course, the usual c++ name mangling incompatibilities.
Thanks for your help!
Oliver
--
Unsubscribe info:
Hi,
I am having the same problem as Frank Stajano
(http://sources.redhat.com/ml/cygwin/2004-04/msg00551.html) and extensive
search of the internet has given me no solution.
I am using the setup.exe file to download all the files to a local
computer, transfer them to another and then install
On Sun, 2004-05-30 at 02:53, Richard Lawrence wrote:
Hi,
...
I've come to the conclusion that either I'm doing something very wrong
(which, if that is the case, it's not clear on what I should be doing) or
that setup.exe is broken when you try to install cygwin in this method.
From an
We are currently porting a linux C++ project to windows. The project
consists of several dll's (or .so's). To recreate those dll's in
Windows it seems like you have to add a lot of __cdecls definitions or
use a definitions file. Neither method is appealing to us. So, I read
somewhere
decorated
the same way (cygwin way). I have also tried to use the
dllwrap and dlltool but all I got was empty def files, and
undefined references.
Please tell me I that I actually can create DLL's in Cygwin
and link them with MSVC. If you do that can you please tell
me how. I spent yesterday
On Wed, 10 Mar 2004 08:59:26 +0100, Niklas Wallin wrote in
[EMAIL PROTECTED]:
We are currently porting a linux C++ project to windows. The project
consists of several dll's (or .so's). To recreate those dll's in
Windows it seems like you have to add a lot of __cdecls definitions or
use
Thanks for your answer Alejandro, I still can't get it right though.
class MyClass
{
public:
MyClass();
~MyClass();
int getValue();
void setValue(int val);
private:
int value_;
};
Try:
cc++ -shared -mno-cygwin -o mydll.dll mydll.cpp \
-Wl,--out-implib=mydll.lib \
On Wed, Mar 10, 2004 at 02:21:41PM +0100, Niklas Wallin wrote:
When I try to link the .lib file with an MSVC executable it still can't
find the references. I am not sure what to expect, should the lib, def
and dll contain Cygwin decorated symbols (which is the case now) or the
MSVC symbols? Or
On Wed, 10 Mar 2004, Christopher Faylor wrote:
On Wed, Mar 10, 2004 at 02:21:41PM +0100, Niklas Wallin wrote:
When I try to link the .lib file with an MSVC executable it still can't
find the references. I am not sure what to expect, should the lib, def
and dll contain Cygwin decorated
On Wed, Mar 10, 2004 at 09:38:06AM -0600, Brian Ford wrote:
On Wed, 10 Mar 2004, Christopher Faylor wrote:
On Wed, Mar 10, 2004 at 02:21:41PM +0100, Niklas Wallin wrote:
When I try to link the .lib file with an MSVC executable it still can't
find the references. I am not sure what to expect,
On Wed, 10 Mar 2004, Christopher Faylor wrote:
On Wed, Mar 10, 2004 at 09:38:06AM -0600, Brian Ford wrote:
On Wed, 10 Mar 2004, Christopher Faylor wrote:
http://cygwin.com/faq/faq_4.html#SEC120
I am probably wrong, as I'm sure cgf is *way* more knowledgable than I,
but I got the impression
Brian Ford wrote:
Because it took me 20 minutes to dig back through the list archives and
find the set of posts that confused me :^\? I still don't think I found
all of them.
With C++, the problem is that it's not just a matter of matching the
mangling scheme - it's a matter of matching the MS
On Wed, 10 Mar 2004 14:21:41 +0100, Niklas Wallin wrote in
[EMAIL PROTECTED]:
Hi Niklas,
Thanks for your answer Alejandro, I still can't get it right though.
You are welcome, but this has truly veered into the realms of the
off-topic.
So in order to pull it back on track, let's do a
when I moved
Yaakov cygclamav-1.dll into my PATH, and even if I call the programs with
Yaakov - --help or --version options. What's going on now??
It happened to me too sometimes. Check the permissions on the dll's
sometimes they do not have the execute permission. Don't know why so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Wilson wrote:
| Make sure that the dll has executable permissions.
| chmod +x cygclamav-1.dll
(and echo from Volker Zell)
I wish it were that easy, but it's not, and I don't know why. When I
run install on it, all the executables are 755 as
Yaakov cygclamav-1.dll into my PATH, and even if I call the programs with
Yaakov - --help or --version options. What's going on now??
It happened to me too sometimes. Check the permissions on the dll's
sometimes they do not have the execute permission. Don't know why so.
Yaakov Yaakov
Ciao
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Wilson wrote:
| Don't use dlltool. It's old and crotchety. Use gcc -shared (or
| libtool). For examples, see the dllhelpers
|
here:http://www.neuro.gatech.edu/users/cwilson/cygutils/dll-stuff/index.html
OK, so I got the dllhelpers-0.4.1 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
| Fribidi is not an easy candidate, they included libtool.m4 as
| acinclude.m4 in the source directory which is really bad since this
| overrides the system libtool.m4 when running configure creats libtool,
| see my patch here:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wrote:
| I got the patch, and if I'm reading it right, then you did the following:
|
| 1) added -no-undefined to libfribidi_la_LDFLAGS
| 2) removed libtool.m4 from acinclude.m4
| 3) autoreconf -i -f -v
|
| Wondering if that's also the problem with
Yaakov Selkowitz wrote:
OK, here's the story. I built clamav after the following steps, and
everything completed without errors, and cygcheck shows the applications
are linked to cygclamav-1.dll. But when I try running one of the
programs that were built, I get a Windows error dialog:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wrote:
| Since you said fribidi has problems, let's move our test case to clamav.
| When I do it this way, it configures fine but make fails horribly:
|
| $ ./clamav-0.66-2.sh build
| cd /home/Yaakov/devel/testing/clamav/clamav-0.66 /bin/bash
|
Hallo Yaakov,
Am Freitag, 13. Februar 2004 um 07:22 schriebst du:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Wilson wrote:
| You might want to use automake+autoconf+libtool, instead of just
| autoconf+libtool.
Do I need to --force these? See below.
I usually run `autoreconf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gerrit P. Haase wrote:
| Hallo Yaakov,
|
| I usually run `autoreconf --install --force --verbose` and add the
| -no-undefined flag where neccessary.
Since you said fribidi has problems, let's move our test case to clamav.
~ When I do it this way, it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, after a lot of time looking at the user guide, FAQ, and Google, I
finally figured out (I think) how to get DLLs to build with the
autotools. But now I'm having troubles with building the executables
from the same package that depend on this
Yaakov Selkowitz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, after a lot of time looking at the user guide, FAQ, and Google, I
finally figured out (I think) how to get DLLs to build with the
autotools. But now I'm having troubles with building the executables
from the same package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charles Wilson wrote:
| You might want to use automake+autoconf+libtool, instead of just
| autoconf+libtool.
Do I need to --force these? See below.
| 2) I added an empty main function to one of the src .c files:
|
| +int main ()
| +{ return 0; }
|
|
Before I reply (privately) the bellow is not sufficient, is it?
-- Forwarded message --
On Tue, Jun 10 2003, at 05:14:57 +0100, Elfyn McBratney wrote:
I saw your project mentioned on one of the Savannah mailing lists. I noticed
that on this page
Does his zip file contain written notice that he will provide the
source if requested for a period of at least 3 years?
Either way, I think this guy is setting himself up for a fall if
he's not archiving versions of the source. You can't get a copy of
3 year old Cygwin source for an arbitrary (or
On Tue, Jun 10, 2003 at 09:52:25PM +0100, Elfyn McBratney wrote:
Before I reply (privately) the bellow is not sufficient, is it?
-- Forwarded message --
On Tue, Jun 10 2003, at 05:14:57 +0100, Elfyn McBratney wrote:
I saw your project mentioned on one of the Savannah mailing
Feel free to forward this to him:
[...]
cgf
Have done. Thank you.
Elfyn
--
Elfyn McBratney (mailto:[EMAIL PROTECTED])
Systems Administrator
ABCtales.com / Ubertales.co.uk
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
I'm trying to use ImageMagik's convert utility with
cygwin. When I run ImageMagik's convert.exe within
cygwin, it complains of missing DLL's.
After running Dependency Walker, it looks like the
missing DLL's that convert.exe needs are:
CYGBZ2-1.DLL
CYGWIN1.DLL
CYGZ.DLL
EFSADU.DLL
I don't think
Hi all,
in december 2002 Charles Wilson and I had supplied an ld patch for the
auto-import from dll functionality.
For the kde-cygwin project we would like to use this new stuff in the near
future for the next qt3 release.
General there are two way to solve this:
Because we don't like to
Ralf Habacker wrote:
Hi all,
in december 2002 Charles Wilson and I had supplied an ld patch for the
auto-import from dll functionality.
For the kde-cygwin project we would like to use this new stuff in the near
future for the next qt3 release.
patience. cgf is the maintainer for binutils on
Ralf Habacker wrote:
Hi all,
in december 2002 Charles Wilson and I had supplied an ld patch for the
auto-import from dll functionality.
For the kde-cygwin project we would like to use this new stuff in the near
future for the next qt3 release.
patience. cgf is the maintainer for binutils on
Ralf Habacker wrote:
Hi all,
in december 2002 Charles Wilson and I had supplied an ld patch for the
auto-import from dll functionality.
For the kde-cygwin project we would like to use this new stuff in the near
future for the next qt3 release.
patience. cgf is the maintainer for binutils on
Ralf Habacker wrote:
Hi all,
in december 2002 Charles Wilson and I had supplied an ld patch for the
auto-import from dll functionality.
For the kde-cygwin project we would like to use this new stuff in the near
future for the next qt3 release.
patience. cgf is the maintainer for binutils on
[sorry for the duplicates; mailserver was fubared. It's fixed now.]
--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/
patience. cgf is the maintainer for binutils on cygwin, but I'm sure he
has his hands full getting ready for the imminent 1.3.19 cygwin kernel
release.
BTW, Danny reported a problem with Fabrizio Gennari's create an export
section for .exe's patch and relocatable linking. Danny sent
1 - 100 of 151 matches
Mail list logo
