Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#650 closed defect (fixed)

Let Darwin/MacOSX use FreeBSD's _ld_extra and _inc_extra initial strings

Reported by: sci-fi@… Owned by: diego@…
Priority: normal Component: build system
Version: HEAD Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: no Analyzed by developer: no

Description

Hi,

This ought to fix part of bug #618, the issue that /usr/local wasn't being
included or linked first through-out the configure script.

Since Diego's recent revamps on the configure script, the $*_extra dirs will be
looked at or used first in most cases.

The simple patch I will submit to this report merely copies the *_extra strings
that set-up FreeBSD's initial dirs, so that darwin builds will use them, too.

I don't trust Apple's gcc to automatically look at these dirs before those
specified on cmd-lines. I feel better if we explicitly specify them.

I imagine other OS.s should be done this way, too, but maybe other people should
okay it first for those systems.

Thank you.

Attachments (1)

configure_darwin_ldextra_like_freebsd.patch (264 bytes ) - added by sci-fi@… 17 years ago.
use FreeBSD's _extra strings in Darwin/MacOSX builds

Download all attachments as: .zip

Change History (5)

by sci-fi@…, 17 years ago

use FreeBSD's _extra strings in Darwin/MacOSX builds

comment:1 by sci-fi@…, 17 years ago

Here's the patch.

comment:2 by diego@…, 17 years ago

Status: newassigned

(In reply to comment #0)

This ought to fix part of bug #618, the issue that /usr/local wasn't being
included or linked first through-out the configure script.

The simple patch I will submit to this report merely copies the *_extra strings
that set-up FreeBSD's initial dirs, so that darwin builds will use them, too.

This should really be fixed at the system level IMO, /usr/local/lib should be in
/etc/ld.so.conf and gcc should be configured to look for includes in
/usr/local/include at the system level ...

comment:3 by sci-fi@…, 17 years ago

(In reply to comment #2)

(In reply to comment #0)

This ought to fix part of bug #618, the issue that /usr/local wasn't being
included or linked first through-out the configure script.

The simple patch I will submit to this report merely copies the *_extra strings
that set-up FreeBSD's initial dirs, so that darwin builds will use them, too.

This should really be fixed at the system level IMO, /usr/local/lib should be in
/etc/ld.so.conf and gcc should be configured to look for includes in
/usr/local/include at the system level ...

Please note that I set "OS" to "Darwin" in this bug's header. I also mentioned
"MacOSX" in the Summary already. And the patch adds the lines to a "darwin"
section in ./configure ... therefore --

There is no such thing as /etc/ld.so.conf for us or anything else like that. At
least the system ignores such files. ;)

(I had some other points to ask, since I had also been using FreeBSD/x86 for a
long time but not any more -- the point I would make is: since when does
FreeBSD's gcc automatically look at the /etc/ld.so.conf list to find the files
to use for -L/-l and -I/-i? See what I mean? But this bug is for Darwin, so I
digress...)

Yes Apple's gcc does search for /usr/local/include by itself but it's not
early-automatic (I hope you know what I mean here). Also, I'm quite sure gcc or
Apple's ld does not automatically link with /usr/local/lib. I said already
repeating myself here again that we want to MAKE SURE the /usr/local trees are
searched EARLY despite all the changes going on in the configure script at
present. You're already doing this for FreeBSD as a special case in the
configure script, so why not make the script act the same way for _other_
platforms, too? That'd be the easiest, wouldn't it?

If almost everyone is having to do this in the --with-extra* parms (adding
/usr/local/whatever there, but does --with-extra* string them early enough?),
then doing this ought to be automatic. Almost every other open source project
does it that way (adds /usr/local explicitly AND EARLY into the searched areas).

I'm just saying Darwin still has enough BSD in it that it needs to benefit from

the treatment that you have in FreeBSD in this case (only).

While I have your eyes here (whoever is reading this), I need to dump a chip off
my shoulder, since the responder said something that kind-of ticked me off, so
please bear with me:

Yes the alterations to the base BSD that are done by Apple/NeXT make it
frustrating to support. Yes I'm getting tired of patching things just because
Apple wants to be different (thus I guess they can hold it as "intellectual
property" ... OTOH Apple _is_ trying to influence the design of BSD [look at
launchd/launchctl] to make it better). Yes Apple promised a long time ago that
OSX was going to be made more "Linux friendly" and YES Apple has been MOVING
FURTHER AWAY from that promise, and I have been quite vocal about it -- but we
can't do anything about it at the present time, okay?!?!? And so YES I am
getting tired of Reimar Doeffinger's and others' comments about Darwin in the
maillists that we are a "fringe group" and thus not big enough to worry about
making open source projects work. Dammit, Darwin _IS_ among the largest
installed base of any kind of *ix there is PERIOD! Don't you-all get it???

So ... this lack of camaraderie for Darwin is only making me angry and driving
me away from submitting any other patches I have to make mplayer work as much as
possible for Darwin/OSX users. This patch is such a stupid little one, but look
how angry I get when the responder obviously doesn't realise what platform it is
for. Esp. how angry I get when people think Darwin is a "fringe group". For
goodness' sakes, PLEASE stop doing this "platform bashing", PLEASE get busy with
looking at our patches, PLEASE offer VALID constructive criticisms (don't just
give us 2 words "patch rejected" without any details, more words is better than
less in this case), and I hope to feel comfortable in continuing with this
endeavour.

Thank you.

comment:4 by diego@…, 17 years ago

Resolution: fixed
Status: assignedclosed

(In reply to comment #3)

(In reply to comment #2)

(In reply to comment #0)

This ought to fix part of bug #618, the issue that /usr/local wasn't being
included or linked first through-out the configure script.

The simple patch I will submit to this report merely copies the *_extra
strings that set-up FreeBSD's initial dirs, so that darwin builds will
use them, too.

This should really be fixed at the system level IMO, /usr/local/lib should
be in /etc/ld.so.conf and gcc should be configured to look for includes in
/usr/local/include at the system level ...

Please note that I set "OS" to "Darwin" in this bug's header. I also
mentioned "MacOSX" in the Summary already. And the patch adds the lines
to a "darwin" section in ./configure ... therefore --

There is no such thing as /etc/ld.so.conf for us or anything else like that.
At least the system ignores such files. ;)

OK, that explains a lot.

Yes Apple's gcc does search for /usr/local/include by itself but it's not
early-automatic (I hope you know what I mean here). Also, I'm quite sure gcc
or Apple's ld does not automatically link with /usr/local/lib. I said already
repeating myself here again that we want to MAKE SURE the /usr/local trees are
searched EARLY despite all the changes going on in the configure script at
present. You're already doing this for FreeBSD as a special case in the
configure script, so why not make the script act the same way for _other_
platforms, too? That'd be the easiest, wouldn't it?

The special case for FreeBSD looks wrong as well. Without intimate platform
knowledge it's hard to tell, though.

And so YES I am
getting tired of Reimar Doeffinger's and others' comments about Darwin in the
maillists that we are a "fringe group" and thus not big enough to worry about
making open source projects work. Dammit, Darwin _IS_ among the largest
installed base of any kind of *ix there is PERIOD! Don't you-all get it???

We're fully aware that OS X has a large *user* base, but it still has a small
*developer* base, at least when it comes to OSS. Plus, it's proprietary.
That's part of the reason why it's so frustrating to support. Getting changes
in at the system level is beyond our control.

Anyway, patch applied.

Note: See TracTickets for help on using tickets.