Re: InetAddr.getLocalHost() [glibc?] bug workaround
>>>>> Geoffrey S Knauth writes: Geoffrey> Joe Carter suggested: >> Change the order of localhost and the real host name in /etc/hosts. >> (real first!). The getlocalhost just seems to get the first it finds. Geoffrey> I tried this straightforward workaround, as silly as it seemed, and Geoffrey> the "GNU/Linux JDK InetAddr.getLocalHost() on glibc bug" vanished Geoffrey> immediately. I'm wondering why someone might have coded things this Geoffrey> way, since ordinarily people don't change their /etc/hosts file every Geoffrey> time they switch between interfaces (e.g., ppp0 at home, eth0 at Geoffrey> work). So I'd consider this a glic bug, unless it turns out the Geoffrey> code in getlocalhost() has a reason behind it. Geoffrey, you mailed this to bug-glibc totally out of context. If you think it's a glibc bug, then please provide a real bug report (the best way is to use the glibcbug script): - What's your problem? - How did you solve it? - Which glibc version are you running? - How can I reproduce it? - What is the code in getlocalhost doing? - ... Please supply if possible a small C program showing the bug - trying to fix a bug which might be in JDK, glibc or whatever might be impossible. Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED]
Re: InetAddr.getLocalHost() [glibc?] bug workaround
>>>>> Roland McGrath writes: > I have a wild suspicion that this is the same problem gated had on redhat 5.0, > and is because there is someplace some code that looks like: > #ifdef IFF_LOOPBACK > if (flags & IFF_LOOPBACK) > ... /* skip this interface */ > #endif > and the headers needed to get that bit have changed somehow. I don't > recall the precise details. Worth checking though. I do think the problem is already solved. We got a bug report[1] (PR libc/667) from Christopher Seawood entitled "glibc fails to return correct hostname if host is listed in /etc/hosts". The problem was a bug in the user program and not in glibc. If PR libc/667 and this bug are different, I'd like to see a real bug report. Andreas Footnotes: [1] The bug database is at http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl - and I know that you, Roland, knows that but I'm not sure about the other recipients of this message. You can read my conversion with Christoper in the bug database. -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED]
Re: JDK can't work with recent glibc
>>>>> SHUDO Kazuyuki writes: > Hi, > I've updated glibc from 2.0.7 to 2.0.110. > Then JDK 1.1.7v1a can't work at all. > Java command says, > % java > /usr/local/java/bin/i586/green_threads/java: error in loading shared libraries: >/usr/local/java/lib/i586/green_threads/libjava.so: undefined symbol: _dl_symbol_value > Glibc 2.0.7 have a symbol _dl_symbol_value but 2.0.110 > don't have it. I need JDK adapted to recent glibc. > Are there any plans? I've had the same problem and send a bug report. One of the blackdown developers told me that this will be fixed in JDK 1.2. The problem is that the JDK port uses an internal symbol (_dl_symbol_value) instead of dlsym - and this internal symbol isn't available in glibc 2.1 (2.0.110 is a test release of glibc 2.1). Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED]
Re: JDK can't work with recent glibc
>>>>> Aaron Gaudio writes: Aaron> I wouldn't recommend glibc 2.0.110 (or 111 for that Aaron> matter). Java isn't the only thing it breaks (try compiling a Aaron> C++ program that uses iostreams). It's not ready for prime time Aaron> just yet. You did read the glibc FAQ that comes with glibc2.0.110 (especially 2.21. What do I need for C++ development?). I don't have problems with iostreams - and neither have seen a bug report from you via the glibcbug script which I would appreciate if there's really a problem. Ok, this is getting off-topic now. Please reply via personal email. Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED]
Re: Java on RedHat Linux 5.2 with glibc-2.0.110
>>>>> Aaron Gaudio writes: > Your problem is related to the version of glibc you are using. The JDK > 1.1.7 uses an internal symbol, _dl_symbol_value, which was present in > glibc 2.0 but is no longer in glibc 2.1, thus the undefined symbol error. > I believe JDK 1.1.6 does not use this symbol and should be fine, although > I have not checked it myself yet. The next JDK release (whether 1.2 or > an upgrade of 1.1.7) should have this fixed. > BTW, glibc 2.1 has been officially released, so you can upgrade it > (although I doubt that will solve your problem here). glibc 2.1 doesn't fix that problem[1] - and I've been also unsuccessful trying JDK 1.1.6 with glibc 2.1 :-(. Andreas Footnotes: [1] since the problem is in JDK - otherwise glibc 2.1 contains a number of fixes;-) -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED]
Re: Information of the glibc-2.1 status on the i386 platform
>>>>> Johan Sundström writes: > Hi > this is not a bugreport :). Still I'm having broblem to run the JDK-1.2 > pre-v1 > on a glibc-2.1 system. I found that someone has reported the same > problem as > I have and the mailinglist contains several posts regarding glibc-2.1 > and JDK-1.2. > The response to the bugreport (id 430) was that a JDK-1.2 with support > for the glibc-2.1 would be uploaded within a few days. It was over a > month ago. > The solution was obviously not a trivial one. Could you please put up > some status about the glibc-2.1 problem/solution on www.blackdown.org > (or simply > make a short note in the README.html file that the jdk-1.2pre-v1 is > known not to work > with glibc-2.1 The README.linux already mentions: Installation Installation of the Linux JDK is trivial. (If you are not on an x86 based Linux system, skip to the bottom of this section). For the x86 processor family, there currently only one flavor, that's based on glibc 2.0 (we will be soon making available a version for glibc 2.1) Note that you must have glibc 2.0 available on your system in order to run all of the JDK properly (you may be able to run some things if you have a glibc 2.1 system, but there are known problems that may prevent you from doing much of anything). You should try to make sure that your glibc 2.0 version is a late version of 2.0.7, like "t" or 20 (depending on how your Linux distribution numbers its package versions). win). I'm running (thanks to the tips in this list!) jdk 1.2pre1 with glibc 2.1. I'm using small wrapper scripts to set the required options, e.g.: $ cat bin/java #!/bin/sh /opt/jdk1.2/bin/java -green -Djava.compiler= $* $ cat bin/appletviewer #!/bin/sh /opt/jdk1.2/bin/appletviewer -green -J-Djava.compiler= $* I just run a few programs and so far everything works for me. Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Information of the glibc-2.1 status on the i386 platform
>>>>> Johan writes: Johan> On 11 Apr 1999, Andreas Jaeger wrote: >> I'm running (thanks to the tips in this list!) jdk 1.2pre1 with glibc >> 2.1. I'm using small wrapper scripts to set the required options, >> e.g.: >> $ cat bin/java >> #!/bin/sh >> /opt/jdk1.2/bin/java -green -Djava.compiler= $* >> $ cat bin/appletviewer >> #!/bin/sh >> /opt/jdk1.2/bin/appletviewer -green -J-Djava.compiler= $* >> >> I just run a few programs and so far everything works for me. Johan> The old applets do indeed work with glibc-2.1 and green threads (using Johan> the above solution). But I still did not get the jfc stuff to work Johan> - not even the demo/jfc/SimpleExample Works without problems on my system (just checked) - and also the SwingSet test (just a bit slow...). Here are details of my system: - i486 with 48 MB (that's why it's slow) - Linux 2.2.5 - recent glibc 2.1.1 development version - XFree86 3.3.3.1 Since the current glibc sources contain a number of bugfixes which also fix problems with glibc 2.0.x compatibility, my usage of the current sources (they're not released yet) might be the significant difference. I'd advise everybody running 2.1 to upgrade to 2.1.1 when it's available (or trying out 2.1.1pre2 which isn't available either - 2.1.1pre1 doesn't help too much). Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RedHat 6, JDK 1.2. native threads & JNI
>>>>> Elena Vorisi & Edoardo Comar writes:
Elena> Hi.
Elena> excuse me, it surely is a newbie question ...
Elena> assuming my system is using glibc2.1, which resides in /lib
Elena> why can't I install a glibc2.0 in a /glibc2.0 directory under my home dir
Elena> and have only selected apps (as for instance jdk12_pre_v1) use it,
Elena> executing them from a shell where I have set :
Elena> export LD_LIBRARY_PATH=$HOME/glibc20:$LD_LIBRARY_PATH
Elena> I hoped this would have allowed me to use glibc20 programs on my rh6 system,
Elena> but I got messages from bash complaining about the version number.
Elena> I guess I should set some other env var, but don't know what.
Elena> I know jdk12 for glibc21 is released, but I would have liked to be able
Elena> to overcome similar issues with other sw ...
This is off-topic here,
Andreas
P.S.: See question 3.18 from the glibc 2.1.1 FAQ:
3.18. After upgrading to glibc 2.1, I receive errors about
unresolved symbols, like `_dl_initial_searchlist' and can not
execute any binaries. What went wrong?
{AJ} This normally happens if your libc and ld (dynamic linker) are from
different releases of glibc. For example, the dynamic linker
/lib/ld-linux.so.2 comes from glibc 2.0.x, but the version of libc.so.6 is
from glibc 2.1.
The path /lib/ld-linux.so.2 is hardcoded in every glibc2 binary but
libc.so.6 is searched via /etc/ld.so.cache and in some special directories
like /lib and /usr/lib. If you run configure with another prefix than /usr
and put this prefix before /lib in /etc/ld.so.conf, your system will break.
So what can you do? Either of the following should work:
* Run `configure' with the same prefix argument you've used for glibc 2.0.x
so that the same paths are used.
* Replace /lib/ld-linux.so.2 with a link to the dynamic linker from glibc
2.1.
You can even call the dynamic linker by hand if everything fails. You've
got to set LD_LIBRARY_PATH so that the corresponding libc is found and also
need to provide an absolute path to your binary:
LD_LIBRARY_PATH= \
/ld-linux.so.2 \
/binary
For example `LD_LIBRARY_PATH=/libold /libold/ld-linux.so.2 /bin/mv ...'
might be useful in fixing a broken system (if /libold contains dynamic
linker and corresponding libc).
With that command line no path is used. To further debug problems with the
dynamic linker, use the LD_DEBUG environment variable, e.g.
`LD_DEBUG=help echo' for the help text.
If you just want to test this release, don't put the lib directory in
/etc/ld.so.conf. You can call programs directly with full paths (as above).
When compiling new programs against glibc 2.1, you've got to specify the
correct paths to the compiler (option -I with gcc) and linker (options
--dynamic-linker, -L and --rpath).
--
Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED]
for pgp-key finger [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of glibc (was: JDK1.2 on Slackware3.5 problems)
>>>>> Nathan Meyers writes: > The difficulty with the JDK1.2/Slackware installation turned out to be a > very incomplete installation of glibc: libc.so.6 had been installed by > copying, but none of the other hundreds of related libraries and support > files was there. > If anyone has some good words of wisdom on putting glibc on a libc5 > system, I'm sure some of the viewers would find the info useful. I know > of some old, detailed instructions to install glibc from source > (http://metalab.unc.edu/LDP/HOWTO/Glibc2-HOWTO.html), but I don't really > know the story for glibc packages. Is it safe to drop in a glibc RPM or > .deb -- does the installation successfully avoid breaking the system? The glibc2-HowTo should mention the case of binary glibc packages. It's not an easy task (neither is installing the sources) but it should work if you take a day or so to read the documentation first (especially glibc2 HowTo and glibc2 FAQ) and have backups handy. Btw. Frodo Looijaard describes a different way installing glibc2 as secondary libc at <http://huizen.dds.nl/~frodol/glibc> (don't know if the link is still valid). > How well do the distribution upgrades handle the migration to a new > glibc? The distributions should do well but using a distribution means AFAIK updating your complete system. > Anyone here have some relevant experience? I'm only a glibc developer - and only switched once from libc5 to glibc;-). Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of glibc (was: JDK1.2 on Slackware3.5 problems)
>>>>> Aniruddha Patro writes: Aniruddha> This might help you folks... Aniruddha> I've a glibc2.1 runtime on a libc5 Slackware 3.5(2.0.34 upgraded to 2.3.2). Aniruddha> Compiled glibc2.1 and installed it under /usr/local/glibc-2.1 Aniruddha> added /usr/local/glibc2.1/lib to /etc/ld.so.conf Aniruddha> Created links Aniruddha> /lib/libc.so.6 to /lib/libc.so.6 Aniruddha> /lib/ld-linux.so.2 to /lib/ld-linux.so.2 Aniruddha> /lib/libm.so.6 to /lib/libm.so.6 The link to /lib/ld-linux.so.2 is the only one neccessary since the rest will be found with ld.so.cache. Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What's so platform dependent with Java2 source?
>>>>> Steve Byrne writes: Steve> [EMAIL PROTECTED] (Nelson Minar) writes: >> Java hits threads very hard. In particular, the native threads port of >> Java stresses the glibc threading framework (and the kernel!) more >> than most systems. So you have to contend not just with portability >> problems, not just bugs in the Java sources, but bugs and misfeatures >> in the Linux implementation too. Steve> Right. LinuxThreads doesn't completely play well with signals. This Steve> causes race conditions. It's messy. We may end up including a (slightly) Steve> custom libpthreads with the release to work around these issues. Jürgen told me already about some of the problems with LinuxThreads. Could anyone from the blackdown team come up with a detailed explanation what's broken - and what's needed? As I'm one of the glibc developers[1] I might try to help get some of these into glibc. Andreas Footnotes: [1] But I don't know enough about linuxthreads to help directly. -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDK 1.2 library problem
On Tue, 21 Sep 1999, Pierre Heroux wrote: > I am using jdk1.2 Classic VM (build Linux_JDK_1.2_pre-release-v2 > glibc2.1, native threads, nojit)on RedHat 5.2. RedHat 5.2 comes with glibc 2.0.7 and not with glibc 2.1.x. Please get the correct JDK release for your platform. > I compile a C++ code which invoke JavaVM. > g++ simple.cpp -I/usr/local/jdk1.2/include -ljava > > I get the following message > > /usr/local/jdk1.2/jre/lib/i386/native_threads/libhpi.so: undefined > reference to `sem_destroy@@GLIBC_2.0' > /usr/local/jdk1.2/jre/lib/i386/native_threads/libhpi.so: undefined > reference to `sem_post@@GLIBC_2.0' > /usr/local/jdk1.2/jre/lib/i386/native_threads/libhpi.so: undefined > reference to `sem_wait@@GLIBC_2.0' > /usr/local/jdk1.2/jre/lib/i386/native_threads/libhpi.so: undefined > reference to `sem_init@@GLIBC_2.0' > > It looks like if I forgot a library but which one ? > Is it an installation problem ? Yes. Andreas -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version for GlibC
>>>>> Peter Pilgrim writes: > Quick GlibC Question? > How do you find what glibc2.x version you have? /lib/libc.so - if you get a segmentation fault, it's glibc 2.0.7;-) For example: $ /lib/libc.so.6 GNU C Library stable release version 2.1.2, by Roland McGrath et al. [...] > I couldn't answer it satisfactorily when asked me this morning. > ( I haven't downloaded JDK pre 1.2 release yet, because 1.1.7v1a > works perfectly fin on SuSE Linux 6.1 which I assume is glibc2.0 anyway.) 6.1 comes with 2.0.7 Andreas -- Andreas Jaeger SuSE Labs [EMAIL PROTECTED] private [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version for GlibC
>>>>> ermirza erekose writes: Please quote correctly. >> On Mon, 8 Nov 1999, Oliver Fels wrote: >> >6.0 is (still) libc5, >> 6.0 is glibc 2.0. > hmmm ... I believe 6.0 is glibc 2.1 Don't mix the distributions: SuSE 6.0 (and we're discussing SuSE here) is libc5 - RedHat 6.0 is glibc 2.1. > The latest glibc is 2.1.2 and will be on SuSE 6.3. >> >> >6.1 is glibc2.0 and >> > 6.2 is based on glibc2.1, >> and 6.3 is glibc 2.1.2 >> >> Bernd -- Andreas Jaeger SuSE Labs [EMAIL PROTECTED] private [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: To use Sniff+... Re: Version for GlibC
>>>>> Robb Shecter writes: > Peter Pilgrim wrote: >> >> Could you print this glibc version info on the shrinked wrapped boxes >> for SuSE 6.3 and for all forthcoming SuSEs. > Hi - while on the topic of Suse, Java and glibc versions, > [ob java+linux] > I want to check out this "Java/Web" version of Sniff+, and have a Suse 6.0 > system. > [/ob java+linux] > I can't, though, because I don't have glibc 2.1. > Is there a document on Suse's Site, or anywhere else, that explains how to > quickly add the glibc 2.1 libraries --just for the purposes of running a > dynamically linked application--? No, there isn't. > I browsed through the www.suse.de site, and couldn't find anything. > There's several (complex) instructions elsewhere on the web about this (ie. > glibc 2 howto), but they're geared for people doing glibc development. > They usually start with "Extract the source distribution...". > I'd think that I shouldn't have to do that! There's really no other way. glibc uses some special paths (specified at compile time) and you can not just place the libraries in another location. It might work - but it might also fail in subtle ways. Putting them in /usr/lib and /lib will break your libc5 system. Either install glibc as a secondary lib (read the HowTo and the FAQ), or get yourself a distribution that comes with glibc 2.1.x. Andreas -- Andreas Jaeger SuSE Labs [EMAIL PROTECTED] private [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
