Achim Gratz writes:
While trying to update PDL I've noticed a strange problem: some GSL XS
modules/DLL reference themselves and those modules that do cannot be
loaded anymore.
I've tried to reprduce this on a different system and see no such
things, so this might be some sort of BLODA.
While trying to update PDL I've noticed a strange problem: some GSL XS
modules/DLL reference themselves and those modules that do cannot be
loaded anymore. This does also affect my installed earlier version of
PDL which has worked before (I've kept the test logs), also when I
freshly compile this
Achim Gratz writes:
While trying to update PDL I've noticed a strange problem: some GSL XS
modules/DLL reference themselves and those modules that do cannot be
loaded anymore.
I've tried to reprduce this on a different system and see no such
things, so this might be some sort of BLODA. Let's
On 12 December 2012 22:50, Angelo Graziosi wrote:
When Cygwin had GCC-4.3.4 as GCC default compiler, I could compile an
application with these steps
g++ -c winbgim.cpp -o winbgim-g95.o
g95 -O3 -Wall -mwindows basic_mods.f90 f03bgi.f90 f03eyes.f90 \
winbgim-g95bis.o -L
On 12/12/2012 10:50 PM, Angelo Graziosi wrote:
When Cygwin had GCC-4.3.4 as GCC default compiler, I could compile an
application with these steps
g++ -c winbgim.cpp -o winbgim-g95.o
g95 -O3 -Wall -mwindows basic_mods.f90 f03bgi.f90 f03eyes.f90 \
winbgim-g95bis.o -L
V. Zeman wrote:
If you are targeting native Windows (no Cygwin) then you can use
No..
Anyway the example I reported works with:
g++, gfortran (Cygwin native)
i686-w64-mingw32-gfortran, i686-w64-mingw32-g++ (Windows native)
and, using Cygwin g++-3 or g++-4.3.4, it works also (Cygwin
Marco Atzeri wrote:
are you mixing compilers ?
Yes... mixing C and Fortran has been standardized (http://fortranwiki.org)
what is g95 pointing to ?
a Fortran compiler ported to Cygwin and other systems (http://www.g95.org)
eventually the orded
No, this cannot work: the .o file depend
On 12/13/2012 3:52 PM, Angelo Graziosi wrote:
Marco Atzeri wrote:
are you mixing compilers ?
Yes... mixing C and Fortran has been standardized (http://fortranwiki.org)
what is g95 pointing to ?
a Fortran compiler ported to Cygwin and other systems (http://www.g95.org)
eventually the
Marco Atzeri wrote:
why not using gfortran as provided ?
I am doing tests and, as I wrote, it works with gfortran and
i686-w64-mingw32-gfortran
(http://cygwin.com/ml/cygwin/2012-12/msg00187.html) and also with G95 if
the C++ code is compiled with g++-3 or g++-4.3.4.
Now I am missing why
When Cygwin had GCC-4.3.4 as GCC default compiler, I could compile an
application with these steps
g++ -c winbgim.cpp -o winbgim-g95.o
g95 -O3 -Wall -mwindows basic_mods.f90 f03bgi.f90 f03eyes.f90 \
winbgim-g95bis.o -L /lib/gcc/i686-pc-cygwin/4.5.3 -lstdc++ \
-s -o f03eyes-g95
Now,
Hello,
I’m pretty new to this whole Cygwin stuff and I have a problem building an
application to an executable.
So let’s start with my little c program.
#include test.h
int main (void){
printf(Hello World);
test();
return 0;
}
int test(void){
return 0;
}
My
[please see http://cygwin.com/acronyms/#PCYMTWLL ]
On 2010-10-07 13:52Z, Michael Jäger wrote:
INCCYGSTDABS = C:/cygwin/usr/include
It's generally preferable to use posix paths with cygwin tools. This
one would be simply /usr/include for example.
LIBCYGSTDABS =
Manually updating the .la file with the correct g++ release number
(which is also what the script does) did the trick.
Thanks!
Johan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Hi,
My application uses the xerces-c-3.0.1 library.
When linking to the library (with libtool), I am getting the following
error message:
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O3 -s -g -O2
-Wl,--enable-auto-import -o libmylib.la mycode.lo -lxerces-c
/usr/bin/grep:
Johan De Taeye wrote:
Note the version of libstdc++ the above is trying to find: 4.3.2
The current version in cywgin is 4.3.4.
It looks to me that the libxerces-c-3.0.1 libraries were created with
an older version of the compiler and are not up to date any more.
Is this a bug? Or am I
On 27/02/2010 17:03, Charles Wilson wrote:
Johan De Taeye wrote:
Note the version of libstdc++ the above is trying to find: 4.3.2
The current version in cywgin is 4.3.4.
It looks to me that the libxerces-c-3.0.1 libraries were created with
an older version of the compiler and are not up to
Yes I do have the ncurses files, I just listed the curses, but for both I
have:
lrwxrwxrwx 1 dev1 None 12 Sep 3 10:35 libcurses.a - libncurses.a
lrwxrwxrwx 1 dev1 None 16 Sep 3 10:35 libcurses.dll.a - libncurses.dll.a
-rw-r--r-- 1 dev1 root 124594 Mar 27 14:21 libncurses++.a
d.henman wrote:
g++ -g -O2 -L../mpegsound -L../nmixer -o nmixer.exe main.o -lncurses
-lnmixer -lpthread -lm -lao -lpthread
../nmixer/libnmixer.a(nmixer.o): In function `_ZN6NMixer14DrawFixedStuffEv':
/usr/src/mp3blaster/mp3blaster-3.2.5/nmixer/nmixer.cc:528: undefined
reference to
Charles,
thank you so much for your help.
d.henman
Charles Wilson cyg...@cwilson.fastmail.fm wrote:
d.henman wrote:
g++ -g -O2 -L../mpegsound -L../nmixer -o nmixer.exe main.o -lncurses
-lnmixer -lpthread -lm -lao -lpthread
../nmixer/libnmixer.a(nmixer.o): In function
Using:
cygwin 1.7.0(0.212/5/3) 2009-08-20
gcc (GCC) 4.3.4 20090802 (prerelease)
ln --version --- ln (GNU coreutils) 7.0
ncurses (runtim lib and devel)
Description: I attempted to build what should be a very simple build, but wound
up with linking errors, which
d.henman wrote:
in lib there is for curses:
lrwxrwxrwx 1 dev1 None 12 Sep 3 10:35 /lib/libcurses.a - libncurses.a
lrwxrwxrwx 1 dev1 None 16 Sep 3 10:35 /lib/libcurses.dll.a -
libncurses.dll.a
You should have the libncurses .a files to which those symlinks point, but
don't. Have you
Dave,
thanks for your detailed answer.
Angelo
Dave Korn wrote:
http://cygwin.com/ml/cygwin/2006-09/msg00444.html
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation:
On 15 September 2006 22:52, Angelo Graziosi wrote:
I have applied what you suggested since then and have built happily many
applications with G77, GCC 3.4.4-2 (CERNLIB, ROOT, Emacs-cvs...).
Now I have discovered these strange linking problems trying to change
somethings in the procedure to
Dave Korn wrote:
Can we then assume that the cernlib build process is doing something
unneccessary or unusual or incorrect?
What would be 'unusual or incorrect' in
$ cat hello.F
program hello
implicit none
write(*,*) 'Hello!'
end
(1)
$ g77 hello.F -o hello
Angelo Graziosi wrote:
Dave Korn wrote:
Can we then assume that the cernlib build process is doing something
unneccessary or unusual or incorrect?
What would be 'unusual or incorrect' in
$ cat hello.F
program hello
implicit none
write(*,*) 'Hello!'
end
(1)
$ g77
I would know if the following is a normal behaviour...
program hello
implicit none
write(*,*) 'Hello!'
end
$ g77 hello.F -o hello -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -lg2c
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab):
undefined
I wrote:
I would know if the following is a normal behaviour...
program hello
implicit none
write(*,*) 'Hello!'
end
$ g77 hello.F -o hello -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -lg2c
On 15 September 2006 14:05, Angelo Graziosi wrote:
program hello
implicit none
write(*,*) 'Hello!'
end
$ g77 hello.F -o hello -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -lg2c
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab
):
undefined
Dave Korn wrote:
Using your hello world testcase, I found that
g77 hello.F -o hello
just works.
Yes, it works.
You don't mention that you've tried this but I assume you
did and it didn't work. So please try the fix I suggested in
Hi
I have an archive libminipar.a. I have a C++ program pdemo.cpp that
makes use it. I am pasting the contents of the makefile at the end of
this email. When I compile the program on linux, I get no errors.
However, when I compile it on cygwin using g++ version 3.4.4, I get
the following
On 14 June 2006 19:01, Ganesh Ramakrishnan wrote:
I have an archive libminipar.a. I have a C++ program pdemo.cpp that
makes use it.
...When I compile the program on linux, I get no errors.
However, when I compile it on cygwin using g++ version 3.4.4, I get
the following linking
I have just installed cygwin along with make,crypt, libcrypt, openssh,
openssl-devel and gcc. When compiling code that is known to work with
cygwin, the linker says it cannot find -lssh. I have googled to the
end of the results for 2 days now, and any help would be much
appreciated. Here is the
Base64 wrote:
I have just installed cygwin along with make,crypt, libcrypt, openssh,
openssl-devel and gcc. When compiling code that is known to work with
cygwin, the linker says it cannot find -lssh. I have googled to the
end of the results for 2 days now, and any help would be much
At 02:14 AM 11/26/2004, you wrote:
Dear All,
I use RegisterDeviceNotification Win32 API in my
program. While compiling under cygwin, linker reports
that cannot find _RegisterDeviceNotification symbol.
And I searched and found that
RegisterDeviceNotification's text is contained in
libuser32.a,
Dear All,
I use RegisterDeviceNotification Win32 API in my
program. While compiling under cygwin, linker reports
that cannot find _RegisterDeviceNotification symbol.
And I searched and found that
RegisterDeviceNotification's text is contained in
libuser32.a, but its symbol is appended @12,
Hallo cygwin,
Libtool tries to link:
sh ./libtool --mode=link g++ -avoid-version -rpath /usr/lib
-no-undefined -o libdbxml-1.2.la
ANTLRUtil.lo ASTFactory.lo ASTNULLType.lo ASTRefCount.lo BaseAST.lo
BitSet.lo CharBuffer.lo CharScanner.lo CommonAST.lo
CommonASTWithHiddenTokens.lo
by the linker; with
Glx excluded the symbol resolved without warning.
The linking problem is now mostly resolved. Now we must figure out how
to get stdcall added to all function definitions for the OpenGL headers.
I think one part of this is to just disable building of Mesa, which
should
Larry Hall wrote:
libtool: link: cannot find the library `/GCC/gcc-3.3.1-3/.inst/package-
gcc/usr/lib/./libstdc++.la'
It's hard to work with partial problem reports.
My WAG is that you didn't install the gcc-g++ package. If that's true, do
so. If it's not, do a 'cygcheck -c gcc-g++'. If the
At 07:22 PM 2/6/2004, Goran Frehse you wrote:
Hi,
I'm trying to compile a project made in Mandrake Linux under Cygwin.
It goes fine until the following message:
libtool: link: cannot find the library `/GCC/gcc-3.3.1-3/.inst/package-
gcc/usr/lib/./libstdc++.la'
The Cygwin installation is fresh
Hello,
Hope someone can help me with this. I've been trying to compile an app
ccze (a log colorizer) under cygwin. The src is here:
ftp://bonehunter.rulez.org/pub/ccze/stable/pre/ccze-0.1.190.tar.gz
This compiles and runs fine under Debian linux and FreeBSD. It also
compiles and runs fine
Hi again,
Sorry, should have probably added, I'm using pcre3.7 and gcc 3.2. I've
included the entire output from the make process below:
thanks
jon.
jon@shuttle (.../tmp/ccze-0.1.190) % make
make -C doc all
make[1]: Entering directory `/home/jon/tmp/ccze-0.1.190/doc'
sed -e
convenience.
Igor
On Mon, 23 Dec 2002, Trimurthi, Swamy(IE10) wrote:
Hi Pechta,
I found your mail id while searchig for some solution on the internet
regarding a linking problem I am facing. It would be of great help to me if
I can get some guidance from you. I am using cygwin version
]
Subject: Re: linking problem, please help
Trimurthi,
The cygwin mailing list is the proper place for such inquiries. It is
strongly discouraged to send personal mail with such requests, and they
will, in general, be ignored. I've forwarded this request to the proper
mailing list
Well, in your code:
#includeiostream
int main()
{
cout\n hello world;
return 0;
}
I see one thing wrong. The cout functions name comes from
the standard namespace, so you either have to add:
using namespace std;
or qualify the name, i.e.
std::cout
I don't know if that
]
Date: Mon, 23 Dec 2002 07:17:48 -0700
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: linking problem, please help
Hi Igor,
Thanks for the information and guidance. I will avoid sending
personal mails hereafter.
regards,
Trimurthi
-Original Message-
From: Igor
Hi. i'm trying to link a simple program using X11 and a com port. the
include and lib paths seem fine. The problem is with undefined references
during linking:
If in the makefile I link with static libraries (XLIB = ${XPATH}/lib/), I
get lots of X related link errors such as: xdisplay.c:
Fixed in jpeg-6b-7
--Chuck
Charles Wilson wrote:
Please keep cygwin related topics on the cygwin list. I've redirected
this mail there, and reset the Reply-To address for your convenience.
The jpeg library, as distributied by the official Independent Jpeg
Group and by cygwin, is NOT
You won't be able to do this (at least ATM). MSVC and gcc use different
ways to describe the C++ symbols.
Guenther Sohler wrote:
Hallo Group,
I downloaded the qt-2.3 library for windows. these have visual studio 6.0
library format., and i want to link
the libraries to my object files to
Hallo Group,
I downloaded the qt-2.3 library for windows. these have visual studio 6.0
library format., and i want to link
the libraries to my object files to generate an exe file.
These libraries are found by the linker, they are accepted - the format is
recognized, but it does not resolve the
49 matches
Mail list logo
