[BUGS] BUG #4219: fseeko test failure in configure script
The following bug has been logged online: Bug reference: 4219 Logged by: Nathan Reed Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Sparc Solaris 10 - 08/07 release Description:fseeko test failure in configure script Details: It does not matter what parameters I do or do not provide on the configure step, I get the same failure every time: checking for fseeko... (cached) yes checking test program... failed configure: error: Could not execute a simple test program. This may be a problem related to locating shared libraries. Check the file 'config.log' for the exact reason. I have even attempted to re-order the configure.in file to no avail. I wanted a version with ssl support (sunfreeware.com does not provide a built version with the ssl support), but this jacked up problem with fseeko is pushing me to use MySQL because I have been successful in configuring, making, and installing a version with ssl support. Encryption is critical in my environment. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4219: fseeko test failure in configure script
I looked at the config.log file, but I can only discern that it appears to be failing on fseeko in the configure section that loops through tests in the area where there are comments about NetBSD, etc re-rendering of fseeko. Understanding that make is difficult with messaging, the output that was in the config.log did not inspire any confidence in the process. Nathan K. Reed Programmer/Analyst Supervisor of Records group University of California, Irvine Office of Admissions and Relations with Schools (949) 824-9631 At 11:48 AM 6/4/2008, Tom Lane wrote: "Nathan Reed" <[EMAIL PROTECTED]> writes: > It does not matter what parameters I do or do not provide on the configure > step, I get the same failure every time: > checking for fseeko... (cached) yes > checking test program... failed > configure: error: > Could not execute a simple test program. This may be a problem related to > locating shared libraries. Check the file 'config.log' for the exact > reason. This is not related to fseeko, that just happens to be the test before the one that is failing. Did you look into config.log to see what is going wrong? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4219: fseeko test failure in configure script
I am using the gcc 3.4.6 compiler. With all of the needed packages for this config run, I have included the following elements in a script: # ./configure --with-openssl --with-libxml --with-libxslt --with-libraries=/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib --with-includes=/usr/local/ssl/include:/usr/local/BerkeleyDB.4.2/include All of the necessary elements came via pkgadd commands with packages from sunfreeware.com. That site notes the use of gcc 3.4.6 and based upon a previous debacle with Perl/Apache/MySQL where a mixture of gcc compiled packages were included in the SUNWspro compiler configuration and make processes, I don't feel like going through the inflicted pain of incompatible address spacing with the shared objects modules. I am aware of the use of the Sun compiler because I started using it on Solaris 2.6 in 1994. I have attempted to decipher the config.log, but the messaging in there leaves me scratching my head because of what is left out. I am well aware of the shortcomings of make in terms of the messages that come out, but simple things such as the actual test being run are obscured at best. Nathan K. Reed Programmer/Analyst Supervisor of Records group University of California, Irvine Office of Admissions and Relations with Schools (949) 824-9631 At 11:47 AM 6/4/2008, John R Pierce wrote: Nathan Reed wrote: The following bug has been logged online: Bug reference: 4219 Logged by: Nathan Reed Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: Sparc Solaris 10 - 08/07 release Description:fseeko test failure in configure script Details: It does not matter what parameters I do or do not provide on the configure step, I get the same failure every time: checking for fseeko... (cached) yes checking test program... failed configure: error: Could not execute a simple test program. This may be a problem related to locating shared libraries. Check the file 'config.log' for the exact reason. I have even attempted to re-order the configure.in file to no avail. I wanted a version with ssl support (sunfreeware.com does not provide a built version with the ssl support), but this jacked up problem with fseeko is pushing me to use MySQL because I have been successful in configuring, making, and installing a version with ssl support. Encryption is critical in my environment. what compiler/tool stack are you using? what additional libraries? for sparc, I'd highly recommend using Sun Studio, aka SUNWspro, available from sun for free nowdays (installs to /opt/SUNWspro/..., so put that bin in your path before any other compilers) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4219: fseeko test failure in configure script
Tom, LD_LIBRARY_PATH is the correct env var to use. However, you are correct that this hamstrings the generated executable - requiring that the LD_LIBRARY_PATH include all of the shared object libraries in the rc scripts themselves. Regarding the possibility of a bug, I had indicated that I performed the ld command from the command in the postgres build area and did not have an error returned. Here is the listing of the ssl lib area (done with pkgadd): # cd /usr/local/ssl/lib # ls -l total 9004 -rwxrwx--x 1 root root1540 Jun 5 08:49 a.out drwxr-xr-x 2 bin bin 512 Jun 3 11:15 engines -rw-r--r-- 1 bin bin 2290290 May 30 02:54 libcrypto.a lrwxrwxrwx 1 root root18 Jun 3 11:15 libcrypto.so -> libcrypto.so.0.9.8 -r-xr-xr-x 1 bin bin 1559648 May 30 02:54 libcrypto.so.0.9.8 -rw-r--r-- 1 bin bin 404896 May 30 02:54 libssl.a lrwxrwxrwx 1 root root 15 Jun 3 11:15 libssl.so -> libssl.so.0.9.8 -r-xr-xr-x 1 bin bin 302776 May 30 02:54 libssl.so.0.9.8 drwxr-xr-x 2 bin bin 512 Jun 3 11:15 pkgconfig The links are there from libssl to the specific shared object lib and all of the packages I added were built using the gcc compiler. Nathan K. Reed Programmer/Analyst Supervisor of Records group University of California, Irvine Office of Admissions and Relations with Schools (949) 824-9631 At 09:55 AM 6/5/2008, Tom Lane wrote: [ please keep the mailing list cc'd ] Nathan Reed <[EMAIL PROTECTED]> writes: > Here is the dump of the config.log file in the pertinent area: > configure:19839: checking test program > configure:19854: gcc -o conftest -O2 -Wall -Wmissing-prototypes > -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels > -fno-strict-aliasing > -fwrapv -I/usr/local/include/libxml2 -I/usr/local/ssl/include > -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/lib -L/usr/lib > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/ccs/lib > -L/usr/ucblib conftest.c -lxslt -lxml2 -lssl -lcrypto -lz -lreadline > -ltermcap -lrt -lsocket -lm >&5 > configure:19857: $? = 0 > configure:19859: ./conftest > ld.so.1: conftest: fatal: libssl.so.0.9.8: open failed: No such file > or directory > ./configure: line 19860: 641 Killed ./conftest$ac_exeext > configure:19862: $? = 137 > configure: program exited with status 137 Personally I would argue that this is a bug in your operating system ;-) What is happening is that the generated object file just references "libssl.so.0.9.8" without any memory of where it had been found at link time, and if the dynamic linker doesn't search all the same directories as you had -L switches for, you lose. One workaround is to set LD_LIBRARY_PATH (or perhaps LD_RUN_PATH, but never having worked on Solaris I'm not too sure which). This isn't very desirable because you'd have to do the same whenever invoking Postgres programs. It'd be better to alter the dynamic linker's configuration to make sure it searches all of your nonstandard library locations, or if you can't do that move all your libraries into the standard directories. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4219: fseeko test failure in configure script
Does not change anything. I have run the generic configure without any parameters (--with-ssl, etc) and I get the same result. I have done a number of permutations, made sure that bison is in place, etc,etc,etc. I am not getting beyond this linker failure on the test of fseeko and I can run the ld command from the command line in the postgres directory context (pointing at the library for ssl that is not opening in postgres configure) and not have an open error returned. I need the ssl encryption capabilities and the only way to enable this functionality is at the configure step. If the Configure script cannot work to provide me this crucial part of the implementation, postgres has no value for my office. I have been able to successfully build MySQL with similar parameter needs implementing openssl. That also uses the configure methodology I don't buy into the bug in Solaris and or that the SUNWspro compiler should be used. If fact, for the packages that I use from Sunfreeware.com, the gcc 3.4.6 compiler is used for that work and not the Sun compiler. I have seen the shared object address space issues that arise from this compiler incompatibility. I noticed that the config sub-directory uses m4 macro files. Is there something related to this area that I need to consider. For instance, upgrading M4? Nathan K. Reed Programmer/Analyst Supervisor of Records group University of California, Irvine Office of Admissions and Relations with Schools (949) 824-9631 At 04:50 AM 6/6/2008, Peter Eisentraut wrote: Am Donnerstag, 5. Juni 2008 schrieb Nathan Reed: > LD_LIBRARY_PATH is the correct env var to use. However, you are > correct that this hamstrings the generated executable - requiring > that the LD_LIBRARY_PATH include all of the shared object libraries > in the rc scripts themselves. From doc/FAQ_Solaris: """ 3) Why does configure complain about a failed test program? This is probably a case of the run-time linker being unable to find some library, probably libz, libreadline or some other non-standard library such as libssl. To point it to the right location, set the LDFLAGS environment variable, e.g., LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib" export LDFLAGS and restart configure. See the ld(1) man page for more information. """ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4219: fseeko test failure in configure script
I have finally gotten cleanly through the configure step. The documentation for postgres under section 15.5 gives the various options, one of which is the --with-libraries. This option does not seem to work correctly for Solaris 10 with various packages added into /usr/local and /usr/local/ssl. A previous response indicated that the use of LDFLAGS would solve this. However, the documentation in section 15.5 does not give any indications or hisnts about what types of usage are possible. Thus, the suggestion for putting in the following as a template: "-R /usr/local/lib:/usr/sfw/lib..." was the ticket. Thus, my script is as follows: ./configure --with-openssl --with-libxml --with-libxslt --with-libraries=/usr/lib:/usr/local/ssl/lib:/usr/sfw/lib: /usr/local/BerkeleyDB.4.2/lib:/usr/ccs/lib:/usr/ucblib --with-includes=/usr/local/ssl/include:/usr/sfw/include: /usr/local/BerkeleyDB.4.2/include LDFLAGS='-R /usr/local/lib:/usr/local/ssl/lib:/usr/sfw/lib: /usr/local/BerkeleyDB.4.2/lib:/usr/ccs/lib:/usr/ucblib' The pertinent ENV vars are: HOSTTYPE=sun4 PATH=/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin PWD=/u1/installs/postgresql-8.3.1 JAVA_HOME=/usr/java TZ=US/Pacific PS1=# SHLVL=2 OSTYPE=solaris VENDOR=sun MACHTYPE=sparc ++ All of the necessary components with dependencies were brought in from sunfreeware and installed with pkgadd. gcc=3.4.6 as the compiler and primary libgcc. Nathan K. Reed Programmer/Analyst Supervisor of Records group University of California, Irvine Office of Admissions and Relations with Schools (949) 824-9631 At 08:56 AM 6/6/2008, Peter Eisentraut wrote: Am Freitag, 6. Juni 2008 schrieb Nathan Reed: > Does not change anything. I have run the generic configure without > any parameters (--with-ssl, etc) and I get the same result. I have > done a number of permutations, made sure that bison is in place, > etc,etc,etc. Trying countless permutations of unrelated parameters is not going to get you closer to success. And neither is posting generic "I am not getting beyond this linker failure on the test of fseeko" error "descriptions" that have nothing to do with your problem. If you want to get any useful help, post your *exact* command line, and the *exact* output you get on the screen as well as the *complete* contents of files that the error message refers you to. And leave the interpretation to others. As far as I can tell, the problem you post is quite common on Solaris, but without any concrete information, I can't tell you how to fix it. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
