Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 105875 - missing 'so' suffix on applications
missing 'so' suffix on applications
Product: Fedora
Classification: Fedora
Component: automake (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Reed
Brian Brock
Depends On:
Blocks: CambridgeTarget
  Show dependency treegraph
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:
Last Closed: 2004-08-20 00:11:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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

  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:

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.