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 BLOD
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'
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
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
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 ord
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 o
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 native)
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 /lib/gcc/i686-pc-cygwin/
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 /lib/gcc/i6
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, with
[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 = C:/c
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
int main (void){
printf("Hello World");
test();
return 0;
}
int test(void){
return 0;
}
My head
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
Unsubscr
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 ar
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
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: /usr/lib/gcc/i686
Charles,
thank you so much for your help.
d.henman
Charles Wilson 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 `_ZN6NMixer14DrawFixedStu
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 `_
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
-rw-r
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
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 s
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: http://c
On 19 September 2006 23:05, Angelo Graziosi wrote:
> What would be 'unusual or incorrect' in
>
> $ cat hello.F
> program hello
> implicit none
> write(*,*) 'Hello!'
> end
>
> (1)
> $ g77 hello.F -o hello -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -lg2c
>
/usr/lib/gcc/i686-pc-cyg
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 hel
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 -L/usr/l
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
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
> http://www.cygwin.com/ml/cygwin/2006-07
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
):
>> u
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
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o)
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 refer
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 linkin
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 linking
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
> a
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
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
>libuser
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, what'
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 Co
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
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 from the web.
Any help would be greatly appreci
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 "s,@VERSION\@,0.1.1
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 under
From: Trimurthi, Swamy(IE10) [EMAIL PROTECTED]
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,
Trimurth
Well, in your code:
> >#include
> >
> > 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
t; Cc: [EMAIL PROTECTED]
> 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
your
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.
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: undefine
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
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
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 l
Anyone knows why this doesnt work in gcc
#include
int main(){
fp_rnd rnd = FP_RM;
fpsetround(rnd);
}
gcc test.c -lm
:undefined reference to `fpsetround'
Anyone knows what file I need to link to get this function?
Or am i doing something wrong?? Or fpsetround is not available
51 matches
Mail list logo
