Opened 3 years ago

Closed 3 years ago

#21265 closed defect (wontfix)

pynac does not build on Cygwin

Reported by: tscrim Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: porting: Cygwin Keywords:
Cc: embray, jpflori, gouezel, rws Merged in:
Authors: Reviewers: Erik Bray
Report Upstream: N/A Work issues:
Branch: u/embray/ticket-21265 (Commits) Commit: 7b7025bfdbad228b0170282427fe72c0fc126ea0
Dependencies: Stopgaps:

Description

pynac-0.6.8 fails on 7.4.beta0 with multiple definition of functions such as

.libs/libpynac_la-lst.o: In function `std::_List_const_iterator<GiNaC::ex>::operator++()':
/home/Travis/sage/local/var/tmp/sage/build/pynac-0.6.8/src/ginac/container.h:521: multiple definition of `GiNaC::container<std::list>::info(unsigned int) const'
.libs/libpynac_la-inifcns_trans.o:/home/Travis/sage/local/var/tmp/sage/build/pynac-0.6.8/src/ginac/container.h:365: first defined here
collect2: error: ld returned 1 exit status

Change History (18)

comment:1 Changed 3 years ago by embray

Confirmed the same.

comment:2 Changed 3 years ago by embray

This looks to be related to this: http://www.ginac.de/ginac.git/?p=ginac.git;a=commit;h=e5eeee53d814cedc12cd725e76b0eb87859cdd77 But in a different incarnation since (I think?) the ginac that the current pynac is based on is much older?

Not entirely sure why it only appears on Windows, but it wouldn't be the first time that the different linking routines used on Windows expose link issues that don't necessarily appear elsewhere (even if maybe they should).

comment:3 Changed 3 years ago by tscrim

  • Cc rws added

That could be the cause. IDK how much changed in the latest upgrade of Pynac. Ralf, do you have any thoughts on this?

comment:4 Changed 3 years ago by rws

Was there a version that compiled?

comment:5 Changed 3 years ago by tscrim

I recall that some version somewhere in the 7.2 betas worked for me. Erik and/or JP likely have more precise details. Erik had compiled Sage on Cygwin64, which I believe was using 7.3, so probably the Pynac version just before 0.6.8 (which was included in 7.4.beta0). Please correct me if I'm wrong.

comment:6 Changed 3 years ago by tscrim

I can check against 7.3 tonight (I need my machine on my Ubuntu boot to do my work for today).

comment:7 Changed 3 years ago by embray

  • Authors set to Erik Bray
  • Branch set to u/embray/ticket-21265
  • Commit set to 7b7025bfdbad228b0170282427fe72c0fc126ea0
  • Status changed from new to needs_review

Here's a working patch--this doesn't apply to ginac where all incarnations of this issue are already fixed.

I'm not sure what the procedure here is though. Since we basically control pynac should the issue just be fixed in pynac, and pynac upgraded in Sage? Or does it still make sense at this stage to have a patch to pynac in Sage?


New commits:

7b7025bFix building pynac 0.6.8 on Cygwin

comment:8 Changed 3 years ago by embray

I can confirm also that before pynac 0.6.8 it worked.

comment:9 Changed 3 years ago by tscrim

Ralf, do you want to cut a new release of Pynac for this or should we just include this as a Sage patch for now?

comment:10 Changed 3 years ago by rws

I wanted to do a new release tomorrow anyway. We can close this ticket after new Pynac is in Sage.

Thanks for the patch, authorship will be recognized.

comment:11 Changed 3 years ago by embray

Sounds good to me.

comment:12 Changed 3 years ago by embray

In any case it turns out my patch to spkg-install misused some variables in such a way that somehow caused the build to be skipped, while not producing any actual errors; this was very confusing. That said, I had already confirmed that pynac does build properly with the patch--it's only the spkg-install itself that I messed up.

Scratch that. That doesn't seem to be it either. For some reason every time I try to reinstall pynac now it's just a no-op. It doesn't even run the spkg-install. I've never seen this happen before.

Last edited 3 years ago by embray (previous) (diff)

comment:13 follow-up: Changed 3 years ago by rws

Does this mean the Pynac code changes are not confirmed to resolve the issue?

To reinstall Pynac (in the sense that make will pick it up) after changes/patches outside the tarball the patchlevel must be increased, i.e. 0.6.8.p0 in package-version.txt. However, you can skip that by forcing a reinstall with sage -p pynac; make.

comment:14 in reply to: ↑ 13 Changed 3 years ago by embray

Replying to rws:

Does this mean the Pynac code changes are not confirmed to resolve the issue?

It is confirmed. I had already made the changes and built pynac from source (that is actually compiled it).

To reinstall Pynac (in the sense that make will pick it up) after changes/patches outside the tarball the patchlevel must be increased, i.e. 0.6.8.p0 in package-version.txt. However, you can skip that by forcing a reinstall with sage -p pynac; make.

I did bump the patch level. I think there's just some subtle bug in my edits to spkg-install that's causing it to exit prematurely but without error. But I confirmed the patch worked manually before making those changes.

comment:15 Changed 3 years ago by rws

See #21369.

comment:16 Changed 3 years ago by embray

Ah, I see what was wrong. This made patch into an infinite recursion. For some reason that causes bash to just bail. Weird. Anyways it's a moot point, this ticket is superseded by #21369.

comment:17 Changed 3 years ago by jdemeyer

  • Authors Erik Bray deleted
  • Milestone changed from sage-7.4 to sage-duplicate/invalid/wontfix
  • Reviewers set to Erik Bray
  • Status changed from needs_review to positive_review

comment:18 Changed 3 years ago by embray

  • Resolution set to wontfix
  • Status changed from positive_review to closed

Determined to be invalid/duplicate/wontfix (closing as "wontfix" as a catch-all resolution).

Note: See TracTickets for help on using tickets.