mersenneforum.org Msieve: problem linking with other C library
 Register FAQ Search Today's Posts Mark Forums Read

 2010-03-31, 06:43 #1 srawlins   Mar 2010 3 Posts Msieve: problem linking with other C library 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 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.
 2010-03-31, 12:24 #2 jasonp Tribal Bullet     Oct 2004 353610 Posts 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.
 2010-03-31, 16:30 #3 srawlins   Mar 2010 3 Posts 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.
 2010-03-31, 16:48 #4 jasonp Tribal Bullet     Oct 2004 24×13×17 Posts 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 :)
 2010-03-31, 18:12 #5 srawlins   Mar 2010 3 Posts 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?
2010-03-31, 20:36   #6
chris2be8

Sep 2009

111111001102 Posts

Quote:
 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

2010-04-02, 02:05   #7
jasonp
Tribal Bullet

Oct 2004

DD016 Posts

Quote:
 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post fivemack Msieve 11 2013-09-22 23:23 mohamed Msieve 20 2013-08-01 08:27 pgreenw Msieve 1 2012-05-21 03:42 chris2be8 Msieve 5 2010-02-22 18:35 schickel Msieve 5 2006-08-31 03:19

All times are UTC. The time now is 11:04.

Sat Apr 10 11:04:14 UTC 2021 up 2 days, 5:45, 1 user, load averages: 1.33, 1.35, 1.39