Background :
Am trying to build a Slackware Server box similar to a RedHat server.
Some of the basic C application types compile and execute fine.

However for some type of application that have more dependencies, bumped
into an issue that is likely fixed on RH. The error is as below :

=========================================================================
/usr/lib/gcc/i486-slackware-linux/4.2.3/../../../../i486-slackware-linux/bin/ld: errno@@GLIBC_PRIVATE: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS definition in MMMM.so section .bss
MMMM.so: could not read symbols: Bad value
collect2: ld returned 1 exit status
=========================================================================

Googled to find that changing
extern int errno;
to
#include <errno.h>
should resolve the issue.

This is not a solution, since i wouldn't like to change MMMM.so

Further google searches led me to RH fix at :
http://www.sourceware.org/ml/binutil.../msg00299.html and
http://sources.redhat.com/bugzilla/show_bug.cgi?id=414

To confirm that this wasn't an issue on the RH box, was able to compile
the bug.c(link #2 above) as is on RH server as against Slackware.

Have downloaded sources for Slackware 12.1. Will install these.
Would like to have this patch on my Slackware box.

My queries are as below :

Which components need to be patched/rebuilt based on this ?
Would just building/upgrading gcc or whatelse be enough ?

Any links to detailed procedure for same would help ?

Else with 12.2 already out. Can anyone tell if this is fixed in 12.2.
have set this up recently, might just decide to upgrade to 12.2

Thanks for your help and advice.

That patch is meant to be applied to binutils. binutils is easy to re-compile, but you may want to re-compile the rest of the toolchain also which is not so simple. Use the SalckBuild scripts from official Slackware, bump the BUILD number for each: re-compile binutils, then gcc, then glibc then gcc again, installing(using upgradepkg) each package as you go.
Lots luck and make sure you know how to re-cover from a non-bootable machine by re-installing the original binutils, gcc and glibc if things go wrong...

A better bet might be to report the bug to PatV and see if he thinks it should be fixed. That's a pretty old patch, so I wonder of it has already been fixed upstream. You could check the sources for binutils and see if the fix is already in there.

Thanks gnashley,

Had been deterred by the required toolchain build sequence.

Compared the sources, it seems the patch is there in 12.1 already.
Not really sure here though. Some expert view/advice is required.

For me real test would be to have the bug.c below compile successfully
on Slackware 12.2 (i86 platform).

$ cat bug.c
extern int errno;

int main ()
{
printf("errno = %d\n",errno);
return 0;
}

A successfull compile/link with :
$ gcc tls-bug.c -L/usr/lib/nptl


Hopefully someone with a Slackware 12.2 can help me out with this test.
Else i might just upgrade in "goodfaith" and hope for best !!!

Regards,

The little program you supplied (bug.c) won't compile on Slackware 12.2 - it gives the TLS errors - unless you either 1) Change the line :
to be :
or compile it with :
Hope this helps

Thanks Eddy, for having done the test for me.

Now i know upgrade to 12.2 is off for now.
Whether to do a toolchain upgrade or maybe change of distro.

As indicated in first post, i have a reference RH box.
So this is almost a blocker, or too much effort to patch ???

Will take some time to decide !!!

Regards,

Had a more detailed look and some thoughts, and have the following.

- Part of patch ( /* Check TLS symbol. */ .. if ) is not on 12.1 or 12.2
- Unable to install RH7.1 due to HDD compat issue. ( not stated earlier )

Course of action is :
Ask/Try for another still older box that will take RH7.1 - Tough Luck.
Install latest RH, shouldn't have problem with HDD & this TLS issue.
Patch Slackware .... upgrade toolchain .... I am getting ready !!!

Regards,

I would try patching and recompiling the binutils on Slackware and see if that fixes the problem. You can use the official SlackBuild, at least as a guide.

Hello gnashley,

Started on the binutils patch. Have a few elementary questions as well.
As suggested started with the SlackBuild for binutils-2.17.50.0.17

Patched the source file, and retained VERSION as 2.17.50.0.17
Ran the commands from SlackBuild step by step till "make -j6" and
"make info".

Some Questions :
1) Is the VERSION as is above and BUILD=1 good enough to bump the BUILD.
Edit : Changed BUILD to 2 ... to be able to differentiate ...
In addition where should a comment be placed about the patch applied.

2) Beyond "make -j6" the following snippets from SlackBuild concerns me.
==========================================================================
make -j6 || exit 1
make info || exit 1
# Needed to link ksymoops:
make install || exit 1
# We need to clear ldscripts/ because binutils doesn't implement DESTDIR everywhere:
rm -rf /usr/lib/ldscripts /usr/${ARCH}-slackware-linux/lib/ldscripts
# Repopulate it:
make install || exit 1
# Install into the $PKG location:
make install DESTDIR=$PKG || exit 1
# Add fresh ldscripts:
cp -a /usr/${ARCH}-slackware-linux/lib/ldscripts $PKG/usr/lib

==========================================================================

Would the rm -rf /usr/lib/ldscripts ..... make my system go boom !!!
Do i need a single user mode for this step ?
Will need it for upgradepkg for sure.
Would the "make install" install in /usr as configure --prefix=/usr
Have a few users using the machine, so would like to tread carefully.

3) Towards end of SlackBuild also see :
#############################
oprofile links to libbfd so
be sure to recompile that
#############################
How crucial is that for the usual code/compile/link/run/test cycle ?

Before ending i would say would like to stick to Slackware since i don't
like rpms somehow and would prefer learning classic Linux than a distro.

Thanks & Regards,

Yes, just bumping the BUILD number will make upgradepkg handle the new package correctly.
Removing the ldscripts and really installing the neew binutils (make install) won't make your system go boom. If some user is in the process of compiling something, they may get a surprise. I've been building binutils lately, and I found that the "real" 'make install' was unneeded, that is using make DESTDIR=$PKG install worked fine and did install the ldscripts into DESTDIR, so removing the real copies, installing the new ones and copying them from the real root was not needed.

It shouldnn't be too big a deal to re-compile oprofile if you even use that or have it installed. If not, don'T worsyy about it.

binutils is not a system-critical package, so you can upgrade it just fine from a normal runlevel of 3 or 4. There is no need to go into maintenance mode. As far as having other users logged in, that is also no problem -only if a user is compiling/linking something at the moment you upgrade, then they may have a surprise. But even so, I doubt it, because of the way upgradepkg works -it simply overwrites the existing program with the new one on-the-fly, so your system is never without the program at any time.

Thanks gnashley,

Was able to proceed and build the package. By passed the "real make" and related stuff.

Built package, and upgraded. However, this has not resolved issue with bug.c yet.

Regards,

You may have to do the same thing with glibc itself by re-compiling it also. But be sure your system is idle when you upgrade glibc. You need to be in runlevel 1 to do that.

Recompiled and upgraded glibc.
However TLS issue remains.
Wondering if have been going the wrong alley !!!

Could it be that configure options (of glibc etc for RH & Slack) are different. Need to get another handle it seems.

Thanks, learnt quite a lot anyways.

Edit :
In addition the -L/usr/lib/nptl flag is inconsequential.

Try locating the srpm for the RHG glibc sources and look in the spec file to see which options were used to compile it.

Found the right patch for sure !!!

http://sources.redhat.com/ml/libc-al.../msg00016.html
( the earlier one was for linker crash )

Not available in Slackware source.
Also patch in conformance with the known fix for errno TLS issue.

Plan to do the following now :-

Undo the binutils/glibc fix.
Apply this patch for glibc.

Regards,

If you properly bumped the BUILD number for ninutils, you can just use upgradepkg to re-install the original package -upgradepkg works the same to downgrade as to upgrade. And for glibc, just bumpt the BUILD number again for the rebuild.