Dear Ruben,
you can overcome the problem with time.h doing this:
After ./configure
Open the file "Makefile", search for libf2c_la_CFLAGS =
Put -DUSE_CLOCK after libf2c_la_CFLAGS =
Now it looks like libf2c_la_CFLAGS = -DUSE_CLOCK -DSkip_f2c_Undefs ....
Open igraph-0.6\src\f2c\uninit.c
Goto Line 182 or serach for _control87(EM_DENORMAL
comment this line /* _control87(EM_DENORMAL ..... */
Open igraph-0.6\src\f2c\s_paus.c
Goto Line 84 or search for pause();
comment this line /* pause(); */
Regarding my problem, I'm now using ./configure --host=x86_64-w64-mingw32,
as you said, but there is now another error:
...
.libs/libigraph_la-igraph-hrg.o:igraph_hrg.cc:(.eh_frame+0x133): undefined
reference to '___gxx_personality_v0'
collect2.exe: error: ld returned 1 exit status
make[3]: *** [libigraph.la] Error 1
make[3]: Leaving directory '/src/igraph-0.6.5/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory '/src/igraph-0.6.5/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/src/igraph-0.6.5'
make: *** [all] Error 2
I'm getting crazy with this.. Could you try to compile igraph again by
yourself and tell me if you get this working?
I'll appreciate that. Many thanks.
*Matheus Viana*
*Postdoctoral Research Employee*
*Developmental and Cell Biology*
*University of California Irvine*
*
**
*
2013/5/30 <[email protected]>
> Send Mingw-w64-public mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mingw-w64-public digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH] Fix bug in InterlockedOr (JonY)
> 2. Compiling igraph library (Matheus Viana)
> 3. Re: Compiling igraph library (Ruben Van Boxem)
> 4. Re: [Website] Work on a Download page (Adrien Nader)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 30 May 2013 18:39:23 +0800
> From: JonY <[email protected]>
> Subject: Re: [Mingw-w64-public] [PATCH] Fix bug in InterlockedOr
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 5/30/2013 06:45, dw wrote:
> > On 5/24/2013 8:43 PM, dw wrote:
> >> I looked at the hand-crafted and the built-in, and they both generate
> >> the same code. In the end, I went with the __sync_fetch_and_OP()
> >> built-in (attached). The comments above still apply.
> >
> > I'm going to wait for this patch to get committed before sending the
> > next one. It's less confusing that way, although it's taking a little
> > longer than I hoped to get thru them all.
> >
> > If there's anything I can do to help move this along, let me know.
> >
>
> Done as trunk r5876.
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 663 bytes
> Desc: OpenPGP digital signature
>
> ------------------------------
>
> Message: 2
> Date: Thu, 30 May 2013 10:21:00 -0700
> From: Matheus Viana <[email protected]>
> Subject: [Mingw-w64-public] Compiling igraph library
> To: [email protected]
> Message-ID:
> <
> canvnhg_-gjywm9mp306m9mk3fm1lxc3vyzvs5++ew7nzepr...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi List.
>
> I'm trying to compile the igraph library using MinGW64, but it's not
> working, though the 32 bits version compiles well in MinGW.
>
> In the source folder of igraph-0.6.5, the command
>
> ./configure --prefix=c:/mingw64 CC="x86_64-w64-mingw32-gcc"
>
> works fine, and this is the final result:
>
> GraphML format support -- no
> GMP library support -- no
> ... yes
> Debug -- no
> Profiling -- no
>
> After this, during the "make", I got the following error:
>
> .libs/libigraph_la-matrix.o: file not recognized: File format not
> recognized
> collect2.exe: error: ld returned 1 exit status
> make[3]: *** [libigraph.la] Error 1
> make[3]: Leaving directory '/src/igraph-0.6.5/src'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory '/src/igraph-0.6.5/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/src/igraph-0.6.5'
> make: *** [all] Error 2
>
> Do you guys have any idea of how to go around this problem?
>
> Thanks,
>
> *Matheus Viana*
> *Postdoctoral Research Employee*
> *Developmental and Cell Biology*
> *University of California Irvine*
> *
> **
> *
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Thu, 30 May 2013 20:30:03 +0200
> From: Ruben Van Boxem <[email protected]>
> Subject: Re: [Mingw-w64-public] Compiling igraph library
> To: "[email protected]"
> <[email protected]>
> Message-ID:
> <CALc40c8V0Jj8jTb_gHh945=
> [email protected]>
> Content-Type: text/plain; charset="utf-8"
>
> 2013/5/30 Matheus Viana <[email protected]>
>
> > Hi List.
> >
> > I'm trying to compile the igraph library using MinGW64, but it's not
> > working, though the 32 bits version compiles well in MinGW.
> >
> > In the source folder of igraph-0.6.5, the command
> >
> > ./configure --prefix=c:/mingw64 CC="x86_64-w64-mingw32-gcc"
> >
>
> This is wrong. See below.
>
>
> >
> > works fine, and this is the final result:
> >
>
> > GraphML format support -- no
> > GMP library support -- no
> > ... yes
> > Debug -- no
> > Profiling -- no
> >
> > After this, during the "make", I got the following error:
> >
> > .libs/libigraph_la-matrix.o: file not recognized: File format not
> > recognized
> > collect2.exe: error: ld returned 1 exit status
> > make[3]: *** [libigraph.la] Error 1
> > make[3]: Leaving directory '/src/igraph-0.6.5/src'
> > make[2]: *** [all] Error 2
> > make[2]: Leaving directory '/src/igraph-0.6.5/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory '/src/igraph-0.6.5'
> > make: *** [all] Error 2
> >
> > Do you guys have any idea of how to go around this problem?
> >
>
> Yes: the MinGW-w64 Wiki
> <
> http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS#Mingw-w64w32specifics
> >shows
> how to compile using the Unix Autotools.
>
> The correct invocation is:
> ./configure --host=x86_64-w64-mingw32
>
> Note that igraph is currently uncapable of building outside of the source
> tree, which I find very annoying and is in general bad practice. You may
> want to bring this to the developers' attention.
>
> I ran into a compile error though:
>
> f2c/dtime_.c:16:23: fatal error: sys/times.h: No such file or directory
> #include "sys/times.h"
> ^
>
> which is caused by this code:
> #ifndef USE_CLOCK
> #define _INCLUDE_POSIX_SOURCE /* for HP-UX */
> #define _INCLUDE_XOPEN_SOURCE /* for HP-UX */
> #include "sys/types.h"
> #include "sys/times.h"
> #ifdef __cplusplus
> extern "C" {
> #endif
> #endif
>
> which needs fixing in the configury part or a Windows implementation. I
> guess the first because it works on MinGW. A quick glance over the
> configure script showed me nothing that could apply here.
>
> Ruben
>
>
> > Thanks,
> >
> > *Matheus Viana*
> > *Postdoctoral Research Employee*
> > *Developmental and Cell Biology*
> > *University of California Irvine*
> > *
> > **
> > *
> >
> >
> >
> ------------------------------------------------------------------------------
> > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> > Get 100% visibility into your production application - at no cost.
> > Code-level diagnostics for performance bottlenecks with <2% overhead
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap1
> > _______________________________________________
> > Mingw-w64-public mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Thu, 30 May 2013 21:46:57 +0200
> From: Adrien Nader <[email protected]>
> Subject: Re: [Mingw-w64-public] [Website] Work on a Download page
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=utf-8
>
> On Thu, May 30, 2013, Ruben Van Boxem wrote:
> > 2013/5/20 Adrien Nader <[email protected]>
> >
> > > Hi,
> > >
> > > I've started working on a download page for the website. Currently the
> > > download links point directly to the sourceforge file listing but
> that's
> > > not enough for the users to be able to chose the right(tm) download.
> > >
> > > The page I've done is at:
> > > http://notk.org/~adrien/picker.php
> > >
> > > It's mostly an HTML shim with javascript and a list of toolchain
> > > descriptions to generate the page content. The php bit is only there to
> > > provide an "include" directive to easily and cleanly provide a default
> > > download list if the user doesn't have JS[1].
> > >
> > > As you can see on the page, besides the layout which isn't perfect, the
> > > toolchain descriptions are completely wrong. If you maintain such a
> > > toolchain and wish to be listed on the download page, please provide me
> > > with a toolchain description.
> > > The process to update the list on the server is not decided yet but for
> > > now, please reply to this email with JS code that creates one or more
> > > objects like in http://notk.org/~adrien/toolchains.js .
> > >
> > > There should also be a way to filter based on compile-time
> > > configuration. In particular, the setting for C++ exception matters a
> > > lot.
> > > I haven't added this yet because I lack visibility about them (how many
> > > of them are there in practice?). As such, please also mention such
> > > specific settings that you might have for your toolchains and once
> there
> > > is a clearer picture, the code can follow.
> > >
> > > Don't hesitate to mention anything that may be missing on my page (no,
> I
> > > won't add ponies).
> > > For additional reference, here is a page that Jon_Y had done some time
> > > ago with a similar goal and a very different implementation:
> > > http://mingw-w64.sourceforge.net/picker.php
> > >
> >
> > I don't mean this in a bad way, but jon_Y's page seems a lot more direct
> to
> > me. Perhaps a bit of explanation about what target,host, etc. mean, but
> > pull-down menus seem more intuitive than checkboxes as far as filtering
> > goes.
>
> No offense taken. The page I've made tries to show much more information
> and that comes at the cost of more complexity.
> There are many many differences between the available toolchains and
> it's simply impossible to have a proper coverage while keeping
> everything even remotely exhaustive without adding more things to the
> page. There is more than half-a-dozen sources of binaries.
>
> The page I've linked to is by no mean final however. It clearly needs a
> "frame", i.e. theming, better explanations, ... What is currently there
> is more like an engine. Fighting javascript's non-existant error
> reporting along with doing everything through the DOM has taken much
> more time than theming could need.
>
> > I don't think it is a good idea to keep Linux distro's toolchains on this
> > list. There will be many, and they will continually change and be updated
> > etc. How would you track all these very distro-specific changes? Same
> with
> > "additional software". Traditionally on Windows, this has been provided
> by
> > the projects themselves, not the toolchain. Unless you have a repo
> bulging
> > with everything one might need, I don't really see how this could help.
>
> The toolchains of Linux distributions don't change once they're released
> and I've kept Fedora Rawhide out of the list on purpose.
> In any case, they cannot change more often than the Automated Builds do
> and it will be the responsibility of the distribution maintainers to
> provide the relevant information in a suitable format (more on this
> below).
>
> As for the additional softwares, I strongly believe they matter. C++
> makes this even more important because of the incompatible exception
> handling mechanisms.
> I've also never enjoyed having to hunt for unreliable prebuilt binaries
> on tens of websites and software authors don't usually enjoy having to
> build binaries themselves either (tbh, I've seen reactions vary between
> disliking it, hating it and despising it).
>
> However, I'm open about that: the download page is meant to serve the
> users. I'll ask people.
>
> > To provide some of the info you required:
> > - There are three exception handling mechanisms: sjlj (slowest, both 32
> > and 64-bit). dw2 (faster, 32-bit only, no exceptions can be thrown
> accross
> > callbacks), and seh (best, 64-bit only).
> > - There are two libgcc threading variants: win32 and posix. Only the
> > latter allows for the C++11 library's threading to be used.
>
> Thanks, I completely forgot to mention the exception handling
> mechanisms.
> About the threading variants, what is the disadvantage of the posix one?
> Does it depend on pthreads?
>
> > On to the page itself:
> > - I don't think it's a good idea to select on binutils/mingw-w64 trunk
> > versions; some don't use snapshots, information is overkill anyways
> etc...
> > - Perhaps rename "CRT" to "MinGW-w64" or "MinGW-w64 headers and
> > libraries". Just because I'm pedantic about this stuff ;-)
>
> I'm unsure whether the binutils version should be displayed: I can't
> remember anything that would make someone strongly prefer one version
> over another one. Does anyone remember such a case recently?
> I believe the mingw-w64/CRT version matters however. The fact that a
> toolchain doesn't provide the right API can be a blocker. OTOH it might
> not be needed as a filter. I'm going to ponder that.
>
> > How do you plan on updating the picker when e.g. I release a new set of
> > binaries?
>
> Plans, not really. At least, nothing has been decided yet.
>
> The most practical input format is Javascript/JSON. For downloads which
> get updated infrequently, doing the update by hand will be fine. For
> downloads which get daily updates (like the automated builds) it will
> have to be automated, maybe a cron job on sf.net or pulling the data as
> JSON directly from the downloads.
>
> This picker.php page actually works with JS disabled because I've used
> it with JS on, dumped the DOM that got generated from the toolchains
> data and put that inside a file that gets included by PHP.
> That's not something that would be easy to automate but it could be done
> by hand once a week (it takes less than 20 seconds) and the downloads
> would only lag by up to 1 week for people with JS off.
>
> As I said, nothing is set: it's difficult to foresee everything and I'm
> reluctant to try to automate something until the requirements are clear.
>
> > Cheers,
> >
> > Ruben
> >
>
> Thanks,
>
> --
> Adrien Nader
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
>
> ------------------------------
>
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
> End of Mingw-w64-public Digest, Vol 68, Issue 29
> ************************************************
>
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
