Msieve: problem linking with other C library

[srawlins]

Hi all (well, mostly jasonp :) ),

I am working on bindings for msieve to Ruby. One gating but work-around-able problem is that the Ruby library that does links C libraries against Ruby (mkmf) always adds Ruby's include paths before the ones that you specify. So, unfortunately, Ruby's ruby/util.h sits in the include path before msieve's util.h. The resulting problem is that when msieve.h and mp.h both try to
#include <util.h>
they fail, instead including Ruby's ruby/util.h. On my system, I worked around this in about 5 seconds by changing that line to read
#include "util.h"
in both msieve.h and mp.h.

I am not a C expert, but I gather that using the double quotes is more proper in the end, when #including a file in the same directory (ie, in the same package or library).

Can this be changed in an upcoming release of msieve? Nothing broke on my system, but of course I recommending testing the change on multiple platforms before committing to it.

You can see the beginnings of the msieve Ruby gem at http://github.com/srawlins/msieve

Thanks for your time.

[jasonp]

That's a good idea, as these two headers are expected to be included by applications, unlike all the others. I'll update the repo soon.

[srawlins]

Thanks much Jason.

Sincerely enjoying the library. I compiled using msys (1.0.11), gcc (3.4.5), and the not-maintained :( mingw-pthreads library, all on Windows XP. libmsieve.a works very well, as does the demo, msieve.exe.

[jasonp]

Okay. I was planning to switch to -march=native so that 64-bit users didn't have to edit the makefile, but I suspect that only works for gcc > 4.x

Also, in windows the mingw-pthreads library is not needed at all; the code uses windows thread functions only, but the link line in the makefile uses it because non-windows machines must have pthreads and I didn't want even more users to have to edit the makefile :)

[srawlins]

Ah, OK. I was going to mention that I did have to edit the Makefile a tad:

I changed lines 22-23 from
CFLAGS = $(OPT_FLAGS) $(MACHINE_FLAGS) $(WARN_FLAGS) \
-I. -Iinclude -Ignfs -Ignfs/poly
to
CFLAGS = $(OPT_FLAGS) $(MACHINE_FLAGS) $(WARN_FLAGS) \
-I. -Iinclude -Ignfs -Ignfs/poly -I/usr/local/include
(thats where my GMP include is)

and line 50 from
LIBS += -L/usr/local/lib -lgmp -lm -lpthread
to
LIBS += -L/usr/local/lib -lgmp -lm -lpthreadGC2

because of how the mingw-pthread libraries are named. But you are saying I can drop the -lpthread?

[chris2be8]

Originally Posted by jasonp

Okay. I was planning to switch to -march=native so that 64-bit users didn't have to edit the makefile, but I suspect that only works for gcc > 4.x

I think -march=native needs gcc 4.2.x or higher. It worked for me with gcc 4.2.1 but not with gcc 4.1.2.

Chris K

[jasonp]

Originally Posted by srawlins

But you are saying I can drop the -lpthread?

Yes. The only reason I leave it there on windows is because cycgwin has always allowed it, and the pthreads bundle is required in minGW if you install the gcc 4.x release candidate. If you try to compile with the ancient gcc 3.4.5 that is the default in minGW you will get a compile error.