Good mornin,
I'm trying to build lsh-1.4.3 on Solaris 9 sparc 64. I'm failing during the configure script with the error:
"checking size of short... configure: error: cannot compute sizeof (short), 77"
When I check the config.log for more details I notice the additional error:
ld: fatal: library -lutil: not found ld: fatal: File processing errors. No output written to conftest collect2: ld returned 1 exit status
and this is true I don't have the libutil library. Do I really need this library, and if so, is building glibc the only way to get it? I tried taking out the library and the function openpty is what's needed. Are there other workarounds?
I've noticed some Solaris questions on the mailing list, and none dealing with the configure step, how did you guys get past it?
Thanks.
Bryan
Bryan Loniewski brylon@jla.rutgers.edu writes:
Hi,
I'm trying to build lsh-1.4.3 on Solaris 9 sparc 64. I'm failing during the configure script with the error:
"checking size of short... configure: error: cannot compute sizeof (short), 77"
This seems rather weird. Could you send me the relevant extract from config.log? (Or if you're not certain, the whole file).
Also details on what compiler and linker you are using and so on would be helpful (if not visible in the config.log extract).
When I check the config.log for more details I notice the additional error:
ld: fatal: library -lutil: not found ld: fatal: File processing errors. No output written to conftest collect2: ld returned 1 exit status
and this is true I don't have the libutil library. Do I really need this library, and if so, is building glibc the only way to get it? I tried taking out the library and the function openpty is what's needed. Are there other workarounds?
This shouldn't be a problem, you're seeing this because the configure script checks for openpty in libutil (the need for which seems to be obsoleted now, but it shouldn't cause you any problems anyway, AFAICT).
I've noticed some Solaris questions on the mailing list, and none dealing with the configure step, how did you guys get past it?
Chances are that you're seeing a problem we haven't seen before.
Regards
/Pontus
Hi Bryan.
Bryan Loniewski wrote...
I'm trying to build lsh-1.4.3 on Solaris 9 sparc 64. I'm failing during the configure script with the error:
"checking size of short... configure: error: cannot compute sizeof (short), 77"
When I check the config.log for more details I notice the additional error:
ld: fatal: library -lutil: not found ld: fatal: File processing errors. No output written to conftest collect2: ld returned 1 exit status
and this is true I don't have the libutil library. Do I really need this library, and if so, is building glibc the only way to get it? I tried taking out the library and the function openpty is what's needed. Are there other workarounds?
I've noticed some Solaris questions on the mailing list, and none dealing with the configure step, how did you guys get past it?
I was experiencing the same error. I was able to avoid it by not specifying paths for all the required libraries etc as options on the command line with configure, instead setting them in my LDFLAGS and CPPFLAGS environment variables prior to running configure. For me, it seemed that the runtime linking paths (liboop in particular) etc just didn't work into the configuration properly unless I did it this way. It was discussed on this list early last year, but I don't think an explanation or solution became clear.
On Wed, 14 Jul 2004, Pete Naylor wrote:
Hi Bryan.
Bryan Loniewski wrote...
I'm trying to build lsh-1.4.3 on Solaris 9 sparc 64. I'm failing during the configure script with the error:
"checking size of short... configure: error: cannot compute sizeof (short), 77"
When I check the config.log for more details I notice the additional error:
ld: fatal: library -lutil: not found ld: fatal: File processing errors. No output written to conftest collect2: ld returned 1 exit status
and this is true I don't have the libutil library. Do I really need this library, and if so, is building glibc the only way to get it? I tried taking out the library and the function openpty is what's needed. Are there other workarounds?
I've noticed some Solaris questions on the mailing list, and none dealing with the configure step, how did you guys get past it?
I was experiencing the same error. I was able to avoid it by not specifying paths for all the required libraries etc as options on the command line with configure, instead setting them in my LDFLAGS and CPPFLAGS environment variables prior to running configure. For me, it seemed that the runtime linking paths (liboop in particular) etc just didn't work into the configuration properly unless I did it this way. It was discussed on this list early last year, but I don't think an explanation or solution became clear.
That was indeed the case! Thanks Pete. I needed to
./configure LDFLAGS= CPPFLAGS=
and all worked... using --with-lib-path and --with-include-path did not seem to work, although If the developers would like to fix this I can email you the config.log of the 'working' and 'non-working' instances?
On a side note, the 1.4.3 code does not do what I need it to (trusted host based auth only, when trying to run lshd with --no-password --no-publickey it core dumps), I downloaded the latest 1.5.5 development code, and when 'make'ing ran into a snag, a patch is provided below.
diff -ruN lsh-1.5.5/src/client.c lsh-1.5.5.new/src/client.c --- lsh-1.5.5/src/client.c Tue Jun 8 16:50:35 2004 +++ lsh-1.5.5.new/src/client.c Thu Jul 15 13:00:06 2004 @@ -895,10 +895,11 @@ struct exception_handler *e UNUSED) { CAST(background_process_command, self, s); + pid_t pid;
trace("do_background_process\n");
- pid_t pid = fork(); + pid = fork();
switch (pid) {
Bryan Loniewski brylon@jla.rutgers.edu writes:
That was indeed the case! Thanks Pete. I needed to
./configure LDFLAGS= CPPFLAGS=
and all worked... using --with-lib-path and --with-include-path did not seem to work,
Are you saying you used --with-lib-path and --with-include-path with no arg? That's not how they're supposed to be used, if it works at all, it should just be a nop.
Anyway, if you know exactly what LDFLAGS and CPPFLAGS you want to use, setting them on the configure command line is the right thing to do.
If the developers would like to fix this I can email you the config.log of the 'working' and 'non-working' instances?
If you mail me the config.log, I can have a look at it. --with-*-path works for me, on Solaris.
On a side note, the 1.4.3 code does not do what I need it to (trusted host based auth only, when trying to run lshd with --no-password --no-publickey it core dumps),
Sorry, host based authentication is not supported. I think you're the first one who ever asks about that feature. I haven't really thought about it, but I don't want to ever recommend making the lsh client program setuid root. And it seems hard to support host based authentication without making something setuid. Server-only support could be done, I guess, but I'm not sure how useful that is.
I downloaded the latest 1.5.5 development code, and when 'make'ing ran into a snag, a patch is provided below.
Thanks, checked in now. /Niels
Niels Mller wrote...
Bryan Loniewski brylon@jla.rutgers.edu writes:
That was indeed the case! Thanks Pete. I needed to
./configure LDFLAGS= CPPFLAGS=
and all worked... using --with-lib-path and --with-include-path did not seem to work,
Are you saying you used --with-lib-path and --with-include-path with no arg? That's not how they're supposed to be used, if it works at all, it should just be a nop.
In my case, I used those options to configure to give the preprocessor and linker the relevant paths - I didn't leave them blank. For some reason, this always failed with the linker being unable to find liboop during one of the configure tests - basically exactly where Brian struck trouble.
If you mail me the config.log, I can have a look at it. --with-*-path works for me, on Solaris.
Niels, I wonder where your libraries and includes are installed on your Solaris system? If they're all installed under /usr/local then it may be that GCC is finding them there regardless of your configure options - GCC's default path to look for those things is /usr/local. In my case, I install each such library under its own package directory in /opt. For example, /opt/liboop. I am wondering if this only fails for people who use a path for those things outside of the GCC default of /usr/local.
Pete Naylor pete@geckoworks.com writes:
Hi,
Are you saying you used --with-lib-path and --with-include-path with no arg? That's not how they're supposed to be used, if it works at all, it should just be a nop.
In my case, I used those options to configure to give the preprocessor and linker the relevant paths - I didn't leave them blank. For some reason, this always failed with the linker being unable to find liboop during one of the configure tests - basically exactly where Brian struck trouble.
I've now had a look, and this seems rather strange. Apparently the logic for when to add -R flags is broken. Could you please send me [off list] a config.log from one of these failed attempts? This naturally also goes for anyone else experiencing this problem.
/Pontus
Pete Naylor pete@geckoworks.com writes:
Niels, I wonder where your libraries and includes are installed on your Solaris system? If they're all installed under /usr/local then it may be that GCC is finding them there regardless of your configure options - GCC's default path to look for those things is /usr/local.
On the Solaris systems I've used, the libraries are installed under /usr/local/lib, and by default, they are indeed picked up by gcc at link-time. However, the dynamic loader does *not* by default look in /usr/local/lib at run-time, so the default library search results in binaries that link but can't be executed (unless one sets LD_LIBRARY_PATH, which in general is discouraged), and configure complains loudly about that.
So I use ./configure --with-lib-path=/usr/local, in order to get lsh:s configure to add both -L/usr/local/lib and -R/usr/local/lib to LDFLAGS. Works for me, for what ever that's worth.
One known bug is that I think the --with-lib-path parsing breaks if you use directory names with whitespace in them, but I suspect you're seeing some different bug. The config.log from a failing build will be needed to have any chance to sort it out.
/Niels
-
Bryan Loniewski -
nisse＠lysator.liu.se -
Pete Naylor -
Pontus Freyhult