Bug 208679 - Review Request: vamos - Automotive simulation framework
Review Request: vamos - Automotive simulation framework
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
Depends On: 208678
  Show dependency treegraph
Reported: 2006-09-30 00:55 EDT by Tom "spot" Callaway
Modified: 2008-03-12 10:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-12 10:57:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed spec changes (1.58 KB, text/x-patch)
2007-06-26 00:38 EDT, Ralf Corsepius
no flags Details
Proposed diff (2.42 MB, text/x-patch)
2007-06-26 00:41 EDT, Ralf Corsepius
no flags Details
undefined-non-weak-symbol warnings (59.02 KB, text/plain)
2007-07-06 14:36 EDT, Jason Tibbitts
no flags Details

  None (edit)
Description Tom "spot" Callaway 2006-09-30 00:55:24 EDT
Spec URL: http://www.auroralinux.org/people/spot/review/vamos.spec
SRPM URL: http://www.auroralinux.org/people/spot/review/vamos-0.5.5-1.fc6.src.rpm   
Vamos is an automotive simulation framework with an emphasis on thorough
physical modeling and good C++ design. Vamos includes a real-time,
first-person, 3D driving application.

It also includes caelum, which is a program to help make seamless sky boxes from panoramic photos. The image file is mapped onto a sphere and six views are shown. The views are from the center of the sphere looking up (top row), down (bottom row), front, right, back, and left (middle row). When these images are mapped to the faces of a cube and viewed from the center of the cube, the view in any direction is indistinguishable from the view from the center of the sphere. The images for the sky box are extracted by taking a screenshot.
Comment 1 Ralf Corsepius 2006-10-02 03:05:17 EDT
* Please explain in detail, why you want to include a static lib 
or disable it (--disable-static). Feel strongly encouraged to do the latter.

Some further remarks:

1. The configure script produces bogus results:
checking for IceConnectionNumber in -lICE... no

On FC5:

nm -sD /usr/lib/libICE.so | grep IceConnectionNumber
00b1f530 T IceConnectionNumber

2. The *.info-install-rules are broken. The package doesn't ship/build
*-<N>.info etc., just *.info.

Comment 2 Tom "spot" Callaway 2006-10-04 12:37:49 EDT
Nuked the static lib, fixed the -lICE check, fixed the info-install rules.

New SRPM: http://www.auroralinux.org/people/spot/review/vamos-0.5.5-2.fc6.src.rpm
New SPEC: http://www.auroralinux.org/people/spot/review/vamos.spec
Comment 3 Jason Tibbitts 2007-06-24 02:11:41 EDT
Odd that this has sat around for so long.  I tried to build it in mock on x86_64
rawhide but wasn't successful.

I know very little about GL stuff but I guess it needs build dependencies on
mesa-libGLU-devel and freeglut-devel.  Unfortunately even after that it fails to
build.  The output is a mess because of parallel make, so I disabled it and got

Car.cc: In constructor 'Vamos_Body::Car_Reader::Car_Reader(std::string,
std::string, Vamos_Body::Car*)':
Car.cc:547: internal compiler error: output_operand: invalid expression as operand
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
{standard input}: Assembler messages:
{standard input}:29088: Warning: end of file not at end of a line; newline inserted
Preprocessed source stored into /tmp/ccULqHNF.out file, please attach this to
your bugreport.

Sure doesn't look good.  I'm not really sure what to do at this point.
Comment 4 Tom "spot" Callaway 2007-06-25 13:31:38 EDT
Let me revisit this package, it had fallen completely off my radar. I'll put up
new SRPMS and SPEC when its ready to be reviewed.
Comment 5 Ralf Corsepius 2007-06-26 00:38:13 EDT
Created attachment 157850 [details]
Proposed spec changes

I am proposing these changes to you spec.
Comment 6 Ralf Corsepius 2007-06-26 00:41:51 EDT
Created attachment 157851 [details]
Proposed diff

This package's configuration is pretty broken.

To work around them, I hacked its configuration by brute force and reran the
autotools. The result is the patch inside of this attachment.

With this patch and my patched spec applied the package build without problems
on x86_64, i386 and ppc64. 

Probably still needing further fixes: *-devel's Requires.
Comment 7 Tom "spot" Callaway 2007-06-29 18:42:48 EDT
OK, new version of vamos has a much cleaner configuration. I absorbed Ralf's
spec fixes and patched it up so that it builds and runs on rawhide x86_64.


Comment 8 Jason Tibbitts 2007-07-06 14:35:20 EDT
This builds for me on rawhide-x86_64, but I get a huge load of rpmlint complaints:

This one should be easy to fix:
  W: vamos-devel wrong-file-end-of-line-encoding 

The rest are all undefined-non-weak-symbol warnings, 612 of them.  I'll attach
them.  The mangled symbols make it somewhat difficult to know what's going on,
but there are unmangled symbols as well like "tan", "asin", "glGenLists" and
"glClear" which make it seem like these libraries aren't even being linked
against libm or the GL libraries, much less each other.
Comment 9 Jason Tibbitts 2007-07-06 14:36:11 EDT
Created attachment 158683 [details]
undefined-non-weak-symbol warnings
Comment 10 Tom "spot" Callaway 2008-03-12 10:57:53 EDT
Revisiting this after a long time... the good news is that all the
undefined-non-weak-symbol warnings are gone. The bad news is that the code is
still a twisted nightmare of GL pain which simply segfaults. I'm no longer
interested in trying to get this working, so I'm closing this out.

Note You need to log in before you can comment on or make changes to this bug.