2013/5/31 Ruben Van Boxem <vanboxem.ru...@gmail.com>
> 2013/5/31 Matheus Viana <vian...@gmail.com>
>
>> 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?
>>
>
What is the link commandline? It seems libgcc(_eh) isn't linked in. If its
using gcc to link, try with g++ instead.
I'll check this out sometime this weekend.
Ruben
>
>> I'll appreciate that. Many thanks.
>>
>>
>>
>> *Matheus Viana*
>> *Postdoctoral Research Employee*
>> *Developmental and Cell Biology*
>> *University of California Irvine*
>> *
>> **
>> *
>>
>>
>> 2013/5/30 <mingw-w64-public-requ...@lists.sourceforge.net>
>>
>>> Send Mingw-w64-public mailing list submissions to
>>> mingw-w64-public@lists.sourceforge.net
>>>
>>> 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
>>> mingw-w64-public-requ...@lists.sourceforge.net
>>>
>>> You can reach the person managing the list at
>>> mingw-w64-public-ow...@lists.sourceforge.net
>>>
>>> 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 <jo...@users.sourceforge.net>
>>> Subject: Re: [Mingw-w64-public] [PATCH] Fix bug in InterlockedOr
>>> To: mingw-w64-public@lists.sourceforge.net
>>> Message-ID: <51a72c5b.4040...@users.sourceforge.net>
>>> 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 <vian...@gmail.com>
>>> Subject: [Mingw-w64-public] Compiling igraph library
>>> To: mingw-w64-public@lists.sourceforge.net
>>> 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 <vanboxem.ru...@gmail.com>
>>> Subject: Re: [Mingw-w64-public] Compiling igraph library
>>> To: "mingw-w64-public@lists.sourceforge.net"
>>> <mingw-w64-public@lists.sourceforge.net>
>>> Message-ID:
>>> <CALc40c8V0Jj8jTb_gHh945=
>>> fytbbrquvkaubbz6tfzpdbwc...@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> 2013/5/30 Matheus Viana <vian...@gmail.com>
>>>
>>> > 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
>>> > Mingw-w64-public@lists.sourceforge.net
>>> > 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 <adr...@notk.org>
>>> Subject: Re: [Mingw-w64-public] [Website] Work on a Download page
>>> To: mingw-w64-public@lists.sourceforge.net
>>> Message-ID: <20130530194657.ga13...@notk.org>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> On Thu, May 30, 2013, Ruben Van Boxem wrote:
>>> > 2013/5/20 Adrien Nader <adr...@notk.org>
>>> >
>>> > > 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
>>> Mingw-w64-public@lists.sourceforge.net
>>> 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
>> Mingw-w64-public@lists.sourceforge.net
>> 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
