2013/5/31 Matheus Viana <[email protected]>
> 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 ..... */
>
Why comment this line? _control87 should be present in MinGW-w64 (see
http://msdn.microsoft.com/en-us/library/e9b52ceh%28v=vs.71%29.aspx). I
guess the macro needs adapting though.
> 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
>
>
------------------------------------------------------------------------------
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
