Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 105875 - missing 'so' suffix on applications
missing 'so' suffix on applications
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: automake (Show other bugs)
rawhide
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Reed
Brian Brock
:
Depends On:
Blocks: CambridgeTarget
  Show dependency tree / graph
 
Reported: 2003-09-28 17:22 EDT by Christian Schaller
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-20 00:11:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Package that exposes the problem (441.70 KB, text/plain)
2003-09-28 17:23 EDT, Christian Schaller 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Christian Schaller 2003-09-28 17:22:04 EDT 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
Some packages, like musicbrainz or gstreamer-player, seems to build losing the
'so' extension on libraries. This is using the automake 1.7-7 in Severn.
Downgrading to automake-1.6-3 from RH9 makes things work right again. I would
think there is a bug in automake 1.7?

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. download mdk musicbrainz SRPM 
2. fix SPEC to work for RH (just replace %mklibname with a hardcoded one)
3. build package to see issue
    

Actual Results:  all files which where supposed to have a .so* suffix get none
or just the so number as prefix.

Expected Results:  na

Additional info:

attaching the srpm I am using to this bugreport
Comment 1 Christian Schaller 2003-09-28 17:23:04 EDT 
Created attachment 94804 [details]
Package that exposes the problem
Comment 2 Jens Petersen 2003-10-02 22:23:10 EDT 
When I try to build with automake-1.6.3-5 or automake16, adding:

export AUTOMAKE=automake-1.6
export ACLOCAL=aclocal-1.6

before %configure, I get the same result as with automake-1.7.

This is the first report I have seen of this.  Are you sure it's not
a libmusicbrainz problem?

I recommend asking on the bug-automake or automake lists too.
Comment 3 Daniel Reed 2004-08-20 00:11:02 EDT 
This sounds a little too bizarre to have been missed for so long.
Please re-open if you are still able to reproduce. Thanks.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.