Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

farey_symbol.pyx fails to build on Cygwin #13336

Closed
jpflori opened this issue Aug 4, 2012 · 14 comments
Closed

farey_symbol.pyx fails to build on Cygwin #13336

jpflori opened this issue Aug 4, 2012 · 14 comments

Comments

@jpflori
Copy link

jpflori commented Aug 4, 2012

Because of DL_IMPORT stuff in headers generated by Cython and corresponding _ _ imp _ _ prefixes added in object files, farey.o cannot be linked to farey_symbol.o (it could with farey_symbol.dll if we generated it...).

The patch here does not include farey_symbol.h but directly declare the prototype of the needed functions in farey.cpp, with the extern "C" stuff but without the dllspec(import) stuff.

Component: porting: Cygwin

Keywords: cygwin linking

Author: Jean-Pierre Flori

Reviewer: Dmitrii Pasechnik

Merged: sage-5.3.beta1

Issue created by migration from https://trac.sagemath.org/ticket/13336

@jpflori jpflori added this to the sage-5.3 milestone Aug 4, 2012
@dimpase
Copy link
Member

dimpase commented Aug 4, 2012

comment:1

with these flags on, I still get

g++ -shared -Wl,--enable-auto-image-base -L/home/Dima/sage-5.2.rc1/local/lib build/temp.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/farey_symbol.o build/temp.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/farey.o build/temp.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/sl2z.o -L/home/Dima/sage-5.2.rc1/local/lib -L/home/Dima/sage-5.2.rc1/local/lib/python2.7/config -lcsage -lgmp -lgmpxx -lstdc++ -lntl -lpython2.7 -o build/lib.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/farey_symbol.dll -Wl,--enable-auto-import
build/temp.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/farey.o: In function `_ZNK18is_element_general9is_memberERK4SL2Z':
/home/Dima/sage-5.2.rc1/devel/sage/sage/modular/arithgroup/farey.cpp:183: undefined reference to `__imp__convert_to_SL2Z'
[... etc ...]
/home/Dima/sage-5.2.rc1/devel/sage/sage/modular/arithgroup/farey.cpp:655: undefined reference to `__imp__convert_to_cusp'
build/temp.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/farey.o: In function `_ZNK11FareySymbol13get_fractionsEv':
/home/Dima/sage-5.2.rc1/devel/sage/sage/modular/arithgroup/farey.cpp:664: undefined reference to `__imp__convert_to_rational'
build/temp.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/farey.o: In function `_ZNK11FareySymbol20get_pairing_matricesEv':
/home/Dima/sage-5.2.rc1/devel/sage/sage/modular/arithgroup/farey.cpp:705: undefined reference to `__imp__convert_to_SL2Z'
build/temp.cygwin-1.7.16-i686-2.7/sage/modular/arithgroup/farey.o: In function `is_element_GammaH':
/home/Dima/sage-5.2.rc1/devel/sage/sage/modular/arithgroup/farey.cpp:132: undefined reference to `__imp__convert_to_long'
collect2: ld returned 1 exit status

So it looks like that the linker cannot find objects which are part of the Farey module (i.e. from sl2z.o, etc)?!

Looks like some g++/dll linking weirdness to me.

@jpflori
Copy link
Author

jpflori commented Aug 4, 2012

comment:2

Yes...
In fact we'll get the same problem later with the wrapper_* things in ext/interpreter.

What's strange is that I don't remember getting it here the last time.
But I kind of so much tweaked the files back then that it must have been that as well.

I think the problem is as follows:
As convert_* are declared extern in farey_symbol.h (from the public modifier in farey_symbol.pyx) g++ adds _ _ imp _ _ prefixes in farey.o.
Then if you actually build a dll of farey_symbol.cpp alone and link a dll of farey.o alone to it ld is fine.
But when you want to directly link farey_symbol.o and farey.o together, ld whines...

@jpflori
Copy link
Author

jpflori commented Aug 4, 2012

comment:3

And obviously I've deleted my 5.1.rc1 install so I have to figure out what let the files compile the last time :)

@jpflori
Copy link
Author

jpflori commented Aug 4, 2012

comment:4

Replying to @jpflori:

I think the problem is as follows:
As convert_* are declared extern in farey_symbol.h (from the public modifier in farey_symbol.pyx) g++ adds _ _ imp _ _ prefixes in farey.o.
Then if you actually build a dll of farey_symbol.cpp alone and link a dll of farey.o alone to it ld is fine.
But when you want to directly link farey_symbol.o and farey.o together, ld whines...

This seems to be the problem.
If you remove the DL_IMPORT lines in farey_symbol.h (generated by Cython), you'll link correctly.

I've got some ideas from here:
http://stackoverflow.com/questions/3704374/linking-error-lnk2019-in-msvc-unresolved-symbols-with-imp-prefix-but-shoul

@jpflori
Copy link
Author

jpflori commented Aug 4, 2012

comment:5

Patch coming.

@jpflori
Copy link
Author

jpflori commented Aug 4, 2012

Attachment: trac_13336-linking.patch.gz

Fix linking problem.

@jpflori
Copy link
Author

jpflori commented Aug 4, 2012

Changed keywords from none to cygwin linking

@jpflori
Copy link
Author

jpflori commented Aug 4, 2012

Author: Jean-Pierre Flori

@jpflori

This comment has been minimized.

@dimpase
Copy link
Member

dimpase commented Aug 5, 2012

comment:7

OK, this does the trick here. I'll give it a positive review as soon as the patchbot gives OK.
The next stop looks like a ginac-related problem at #13337

@dimpase
Copy link
Member

dimpase commented Aug 8, 2012

comment:8

Looks good.

@jdemeyer
Copy link

jdemeyer commented Aug 8, 2012

Reviewer: Dmitrii Pasechnik

@jdemeyer
Copy link

Merged: sage-5.3.beta1

@jdemeyer
Copy link

comment:11

Real Cython fix in #23004.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants