Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#38770 closed defect (fixed)

atlas 3.10.1_3 +gcc47 +universal fails to build

Reported by: michaelld (Michael Dickens) Owned by: Veence (Vincent)
Priority: Normal Milestone:
Component: ports Version: 2.1.99
Keywords: Cc: cooljeanius (Eric Gallager)
Port: atlas

Description

MacBook Pro Retina, 2.6 GHz Intel Core i7, 8 GB DRAM; Mac OS X 10.8.3 latest; latest MacPorts from svn trunk; latest XCode and command line tools. 3.10.1_2 worked. Attaching compressed build log using "use_parallel_build=no".

Attachments (2)

atlas_3.10.1_3_build.log.zip (182.5 KB) - added by michaelld (Michael Dickens) 11 years ago.
atlas_r105258_build.log.zip (201.0 KB) - added by michaelld (Michael Dickens) 11 years ago.

Download all attachments as: .zip

Change History (14)

Changed 11 years ago by michaelld (Michael Dickens)

comment:1 Changed 11 years ago by michaelld (Michael Dickens)

"3.10.1_2 worked" == built and installed without errors. That version contains undefined _omp_* symbols, which render it difficult to use. 3.10.1_3 fixes the _omp_* symbols. From the log, the x86_64 version built (not without errors, but they were ignored); the i386 version is where the critical errors occur. Not using "use_parallel_build=no" results in the same problem, but the log file is more difficult to read.

comment:2 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:3 Changed 11 years ago by Veence (Vincent)

There was a basic flaw in Portfile, that has been corrected. Could you please try again? Thanks.

comment:4 Changed 11 years ago by michaelld (Michael Dickens)

Got the updated Portfile, cleaned the old build, tried to upgrade: results in the same issue. After looking back through older altas issues, it's almost as if atlas is not recognizing the computer's CPU when in 32-bit mode -- not quite, but similar. I'm not sure this is a MacPorts' issue, but the Portfile is complex enough that I'm not sure. I'll spend some time next week (later in the week) looking into this if it's still an issue then.

comment:5 Changed 11 years ago by Veence (Vincent)

There was a bug in the flag value used to identify the vector unit, so SSE3 did not get detected. Please try again at r105258.

comment:6 Changed 11 years ago by michaelld (Michael Dickens)

Still not working; new errors though :) Attaching new log.

Changed 11 years ago by michaelld (Michael Dickens)

Attachment: atlas_r105258_build.log.zip added

comment:7 Changed 11 years ago by Veence (Vincent)

The problem here is that some values are incoherent. A pre-computed value is used to automatically select a combination of parameters, but that combination happens not to exist in the set of compiled snippets (why???). The most obvious workaround would be to override the pre-selection, but that would be at a cost of downgrading to manual probing which takes hours to complete. I’ll see if there is something cheaper to do.

comment:8 Changed 11 years ago by Veence (Vincent)

Ok, I think I fixed it. The vector unit flag used (6) was set to SSE3, but somehow the build process considers that SSE3 does not imply neither SSE2 nor SSE1, causing some snippets not to be included during the selection process, which in turns leads to the inconsistency aforementioned and the assert trap. So I changed the flag to 448 = SSE3 + SSE2 + SSE1. Seems to work (though my build has not currently completed). I have committed r105311 with this tweak, please try again.

comment:9 Changed 11 years ago by michaelld (Michael Dickens)

Yes, that did fix the install issue; I haven't tried compiling and executing anything with it yet. BUT: it took 3 hours 45 minute to install. I think most of the time was spent doing the manual probing you describe earlier. Not a major issue, but still somewhat annoying; I hope you're able to find a better way to get those parameters in place!

comment:10 Changed 11 years ago by Veence (Vincent)

Resolution: fixed
Status: newclosed

Yes, I’ve noticed that. It might be caused by the new Portfile enabling SSE3 instead of SSE2 for i386 (32-bit build).

Since it seems to work, I close the bug, but I’ll try to downgrade to SSE2 and see if that improves the compiling time.

Last edited 11 years ago by Veence (Vincent) (previous) (diff)

comment:11 Changed 11 years ago by michaelld (Michael Dickens)

Thanks for your persistence and timeliness on this ticket!

comment:12 Changed 11 years ago by Veence (Vincent)

My pleasure! Thanks for your patience! Downgrading to plain SSE2 does not seem to improve the i386 build process. I’ll have to dig further, not tomorrow, but Friday. Meanwhile, have fun!

Note: See TracTickets for help on using tickets.