Re: Duplicate libraries in fox-config output

Unknown if it ever impacted FOX, but many years ago, one had to. Gray 
cells are a bit fuzzy on it, had to do with video card flavored 
libraries and a few third party libraries that would not find one 
library if it was linked ahead of it.

In what could only be an MBA lead "efficiency" move most linkers of the 
day were single pass. While you should never ever under any 
circumstances trust anything on StackOverflow, the answer from this 11 
year old question with a green check mark and 123 up votes does a pretty 
good job of explaining it.

https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-option-in-gcc-matter

Thanks to brain dead AI additions to search engines you can no longer 
search for "how many passes does GNU linker make" without getting 
inundated with links to command line passing.

The comments below that answer tick some memories too. You have to 
remember the x86 has always been and will probably always be the home 
hobby platform. When Intel and Microsoft desperately wanted to get a to 
hold in Fortune 500 data centers they bribed marketing agencies like 
Gartner Group (masquerading as "industry analysts") telling companies 
that systems and libraries needed to conform to "Open Standards." Prior 
to that we had things that actually worked. Your OS/400 programs just 
worked on OS/400. MVS on MVS. VMS on VMS, etc. We had screen and other 
libraries all made by the hardware vendor for the hardware and OS we 
were running on. No, they weren't portable, but they "just worked." We 
used operating systems that were created to be robust multi-user 
platforms that could bill for every byte and clock cycle consumed by 
everyone. It wasn't until MAI, Wang, and a few others started going 
under that portable became something companies worried about. We had 
proprietary security until the vendor went under. We also had linkers 
that operated in one of the following manners:

1) Made N-passes through the libraries trying to resolve external 
linkage. You had a command line switch to limit the maximum number of 
passes. Something says the default for most was up to 4 passes.

2) Loaded _every_ external linkage item from every library on the 
command line into one big lookup table before linking object files. (Our 
libraries had header areas where all this info was so they were only 
reading a few disk blocks from each, not dynamically parsing something.)

3) Both 1 & 2. Towards the end this was what they all did because every 
time you linked another function from another library it could add new 
external dependencies.

After the bust-up of AT&T, UNIX, originally created on a DEC PDP, which 
was never created to be a true multi-user OS, just to run phone switches 
and allow maintenance to log in to tweak/update things, got popped out 
into the world of "free software." There might have been as many as 60 
commercial Unix versions that popped up in the weeks/months following. 
Most of them sucked. None of them were worthy of running a business on, 
though some companies tried. These vendors desperately wanted to get 
into the corporate data center as well. That's where the real money was.

You may remember a name called SUN Microsystems. When you could cobble 
together a generic PC with 40MEG hard drive and two floppies for around 
$800, SUN was selling $20,000 "engineering workstations" to corporations 
that cost about the same to build. They had cash coming out their back 
side and got behind this "standard." There was no way they were ever 
going to get their 
not-really-multi-user-just-multiple-people-could-log-in system into the 
data center unless they could somehow make that sexy to the ones with 
the checkbooks.

Enter POSIX.

A standard that busted every proprietary OS trying to conform to it 
because the ones holding the checkbooks demanded compliance with it. 
With POSIX we got insecurities, data breaches, and a mandate for a 
single pass linker because that is all the 
not-really-multi-user-just-multiple-people-could-log-in systems could 
manage.

Your latest macOS is not POSIX compliant. You should point it out to 
them since Apple was one of the companies behind POSIX back in the day. 
SUN, creators of Java with seemingly limitless financial resources, went 
bankrupt.

As part of this POSIX world Microsoft wanted to make a standard for user 
interaction. They wanted it to be like their feeble DOS and GUI DOS 
(Windows) was capable of. After the initial POSIX debacle IBM flooded 
the standards committee with employees and customers. That is why CUA 
works exactly like a CICS application on a green screen. We tab between 
fields, have a special ENTER key different from the RETURN key, etc.

Why do those of us who worked on real computers have such disdain for 
the x86 platforms despite all of the embedded, Linux, and desktop stuff 
we have written?

On the PDP 11/70 we ran 255 interactive/batch users in 64K-words. The PC 
with DOS and 640K bytes could barely run one.

The current IBM z/OS box, a little shorter and about the same width as 2 
4-drawer file cabinets can run more users that 2 complete floors of 
machines at any cloud data center in the world. I don't think they 
worried about POSIX compliance.

Sorry, the "why" behind your answer is tangled up in an ugly corrupt 
history of the PC world. It appears macOS has now learned the ugly 
truth. POSIX was meant to cripple, not enhance.

When you are written for the least common denominator and all must 
comply, nobody can soar.

Even GNU has figured this out and quietly hidden their nasty undies   
--  GNU is no longer POSIX compliant. Read up on:

--whole-archive      (links everything just like we did with DOS)

--start-group   --end-group    (make N-passes through these libraries 
trying to resolve linkage)



On 7/26/2024 2:02 AM, Michael Behrisch via Foxgui-users wrote:
> Hi,
> I have a question about the output of "fox-config --libs".
> On my system it currently gives: "-L/usr/lib64 -lFOX-1.6 -lX11 -lXext 
> -lfreetype -lfontconfig -lXft -lXcursor -lXrender -lXrandr -lXfixes 
> -lXi -lGL -lGLU -ldl -lpthread -lrt -ljpeg -lpng -ltiff -lz -lbz2 
> -lGLU -lGL"
> which duplicates the GL and GLU libraries.
>
> The problem is that recent macOS builds complain if you link the same 
> library twice.
>
> I had a look at the source code in configure.ac and fox-config.in and 
> this seems to be intentional because indeed the GL libraries (LIBGL) 
> are being added to the LIBS variable and then both are output in the end.
> I removed the first addition of the GL libs and it is still working 
> fine here but before submitting a patch I wanted to ask whether there 
> is a known reason for this duplication because sometimes the linker is 
> tricky.
>
> Thank you and best regards,
> Michael
>
>
> _______________________________________________
> Foxgui-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com



_______________________________________________
Foxgui-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/foxgui-users