UNIXODBC Installation into HP-UX 11.31 iA64

[MissX]

Hello, may I know how to solve this problem where the "unknown input file type" message that appear when I try to install unixODBC onto my HP-UX? FYI, i use the command "./configure", then "make" which result in the error:

Making all in exe
/bin/sh ../libtool --tag=CC --mode=link cc -mt -o isql isql.o ../
DriverManager/libodbc.la ../extras/libodbcextraslc.la -lpthread
libtool: link: cc -mt -o .libs/isql isql.o ../DriverManager/.libs/libodbc.so ..
/extras/.libs/libodbcextraslc.a -lpthread -mt

ld: Unknown input file type: "../DriverManager/.libs/libodbc.so"
Fatal error.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.

libodbc.so file is an executable file and it does exist in the /DriverManager/.libs/ directory. Thanks in advance for the reply.

[Steven Schweda]

> libodbc.so file is an executable file [...]

   What, exactly, does that mean to you?  As usual, showing actual
commands with their actual output can be more helpful than vague
descriptions or interpretations.

      file ../DriverManager/.libs/libodbc.so

   How was this libodbc.so created?

[Dennis Handly]

> libodbc.so file is an executable file

No, this is a shlib.  As Steven said, knowing what type and architecture would be helpful.

[MissX]

Thank you so much for the replies!! Actually, I am trying to install MySQL Connector ODBC into the HP-UX server but it showed an error message.

This is the command that I used to install MySQL Connector ODBC:

#myodbc-installer -a -d -n "MySQL ODBC 5.1.8 Driver" -t "/z/install/mysql-connector-odbc-5.1.8-hpux11.31-ia64-64bit/lib/libmyodbc5.so"

And this is the error message that I got:

/usr/lib/hpux64/dld.so: Unable to find library 'libodbc.so.1'.

Killed

Therefore, after that, I realize that I need to install unixODBC into the HP-UX in order for the MySQL Connector ODBC to work.

This is the command that I used to install unixODBC:

# ./configure

# make

And this is the error message that is shown after I run the command # make:

Making all in exe
/bin/sh ../libtool --tag=CC --mode=link cc -mt -o isql isql.o ../
DriverManager/libodbc.la ../extras/libodbcextraslc.la -lpthread
libtool: link: cc -mt -o .libs/isql isql.o ../DriverManager/.libs/libodbc.so ..
/extras/.libs/libodbcextraslc.a -lpthread -mt

ld: Unknown input file type: "../DriverManager/.libs/libodbc.so"
Fatal error.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.

Regarding how the libodbc.so is created,  I think it is already inside the DiverManager/.libs/ when I extracted the unixODBC-2.3.4.tar file.

This is the link where I downloaded the unixODBC-2.3.4.tar file:

http://www.unixodbc.org/download.html

Do I need to provide anything else in order for you to better understand the problem I faced?

Thanks!  \(^v^)/

[Steven Schweda]

> Regarding how the libodbc.so is created,  I think it is already there
> inside  the DiverManager/.libs/ when I extracted the unixODBC-2.3.4.tar
> file.

   Not likely,  A ".so" shared object is a compiler+linker product, not
a source file.  Also, there's no evidence of it being there:

mba$ gzip -dc unixODBC-2.3.4.tar.gz | tar tf - | grep '\.so'
mba$

   Knowing nothing, my guess would be that the ".so" is not being built
correctly.

> Do I need to provide anything else in order for you to better understand
> the problem I faced?

   For a start, the same as before:

      file ../DriverManager/.libs/libodbc.so

   Always nice:

      uname -a

>    How was this libodbc.so created?

   Still a mystery.  You may need to save the "make" output, and scan it
to find the actual command.  If the "make" file hides its actions, then
you may need to study the "make" file(s) to find the command(s) used.

> libtool: link: cc -mt -o .libs/isql isql.o \
>  ../DriverManager/.libs/libodbc.so ..

   If "libtool" is used to create the the ".so", then the problem might
be a bad "libtool" (or bad libtool options).

[MissX]

Once again thanks for the reply. This time, we actually deleted all the unixODBC installation file before we gunzip and tar the new file.

> uname -a 

HP-UX PA30 B.11.31 U ia64 

> file ../DriverManager/.libs/libodbc.so

I tried this command too, but the message displayed is cannot open.

> # gzip -dc unixODBC-2.3.4.tar.gz | tar tf - | grep '\.so'

We try the above command but nothing happens.

Then, we try to extract the file once again using the following command:

# gunzip unixODBC-2.3.4.tar.gz

# tar -xvf unixODBC-2.3.4.tar

>    How was this libodbc.so created?

We directed into ../DriverManager and the .libs directory is not found. Then, we use # ./configure command and the result is that the .libs directory is still not found.

After that, we use #make command and indeed the .libs directory which contain libodbc.so is created during that time. 

But unfortunately, the same error message is displayed.

(Bundled) cc: warning 922: "-b" is unsupported in the bundled compiler, ignored.
ld: (Warning) Unsatisfied symbol "main" in file /usr/lib/hpux32/libc.so
1 warning.
libtool: link: (cd ".libs" && rm -f "libodbc.so.2" && ln -s "libodbc.so.2.0" "li
bodbc.so.2")
libtool: link: (cd ".libs" && rm -f "libodbc.so" && ln -s "libodbc.so.2.0" "libo
dbc.so")
libtool: link: rm -fr .libs/libodbc.lax
libtool: link: ( cd ".libs" && rm -f "libodbc.la" && ln -s "../libodbc.la" "libo
dbc.la" )
Making all in exe
source='isql.c' object='isql.o' libtool=no \
DEPDIR=.deps depmode=hp2 /bin/sh ../depcomp \
cc -DHAVE_CONFIG_H -I. -I.. -I../include -I../libltdl -mt -c isql.c
/bin/sh ../libtool --tag=CC --mode=link cc -mt -o isql isql.o ../
DriverManager/libodbc.la ../extras/libodbcextraslc.la -lpthread
libtool: link: cc -mt -o .libs/isql isql.o ../DriverManager/.libs/libodbc.so ..
/extras/.libs/libodbcextraslc.a -lpthread -mt
ld: Unknown input file type: "../DriverManager/.libs/libodbc.so"
Fatal error.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.

I totally have no idea on how this command works as I am a total newbie in HP-UX and it is my first time dealing with a server. I'd be more than happy if you or anyone else can help me solve this problem.

>  If that's (related to) the command that makes the ".so", then the problem might be a bad "libtool" (or bad libtool options).

Is there any way you can guide me in ensuring the correct libtool or libtool options?

Thanks!

[TTr]

If your "configure" and/or "make" commands fail, I would expect that the libodbc.so.1 either does not exist because it was never created or it is of the wrong format.

You might want to step back and tell us exactly what you did from the begining and not just ask why the libodbc is not working. Things like what ODBC source packages did you download, from where and all the commands you used before the "configure/make". and the "myodbc-installer".

[Steven Schweda]

> [...] This time, we actually deleted all the unixODBC installation
> file before we gunzip and tar the new file.

> > file ../DriverManager/.libs/libodbc.so
> I tried this command too, but the message displayed is cannot open.

   Well, yeah.  If you delete all the generated files, then that one
won't be there.

> > # gzip -dc unixODBC-2.3.4.tar.gz | tar tf - | grep '\.so'
> We try the above command but nothing happens.

   What happened was not "nothing".  What happened was that that no
".so" file was found.  Which means that it was not in the kit (as you
had claimed).  As I wrote:

> > Regarding how the libodbc.so is created,  I think it is already there
> > inside  the DiverManager/.libs/ when I extracted the unixODBC-2.3.4.tar
> > file.
>
>    Not likely,  A ".so" shared object is a compiler+linker product, not
> a source file.  Also, there's no evidence of it being there:
>
> mba$ gzip -dc unixODBC-2.3.4.tar.gz | tar tf - | grep '\.so'
> mba$

   That command simply showed that there was no ".so" anywhere in the
kit.

> # gunzip unixODBC-2.3.4.tar.gz
> # tar -xvf unixODBC-2.3.4.tar

   If you don't need to keep the ".tar" file, then:

      gzip -dc unixODBC-2.3.4.tar.gz | tar xf -

I normally don't use "v" in such cases.  It's too easy to miss an error
message in a flood of "v" messages.

> But unfortunately, the same error message is displayed.
>
> (Bundled) cc: warning 922: "-b" is unsupported in the bundled compiler,
> ignored.

      man cc

What does "-b" do?  My Web search for "hp-ux cc options" found:
[...]
      -b             Cause the linker ld(1) to create a shared library
                     rather than a normal executable file.  Object files
                     processed with this option must contain position
                     independent code (PIC).  For details see ld(1), HP-UX
                     Linker and Libraries Online User's Guide and the
                     Programming on HP-UX manual.
[...]

   So, you apparently need to use a real C compiler if you expect to use
it to create a shared object/library (".so").  The "Bundled" C compiler
has been crippled so that it can't do some tasks.  This is one of those.

   To get a real compiler, you can buy one from HPE or you can install
the (free) GCC.


> > file ../DriverManager/.libs/libodbc.so
> I tried this command too, but the message displayed is cannot open.

   Did you try it _after_ the build made a non-shared-object file named
"libodbc.so"?  _That_ might have told us something.

> ld: Unknown input file type: "../DriverManager/.libs/libodbc.so"

   As I wrote:

>    Knowing nothing, my guess would be that the ".so" is not being built
> correctly.

   Still true.  But now we know why.

[Steven Schweda]

> But unfortunately, the same error message is displayed.
>
> (Bundled) cc: warning 922: "-b" is unsupported in the bundled compiler,
> ignored.

   For the record, to _you_, this may be "the same error message", but
it's the first time that the rest of us have seen it.

[Dennis Handly]

> (Bundled) cc: warning 922: "-b" is unsupported in the bundled compiler, ignored.

You can't build shlibs with the bundled C compiler.  You must purchase a C/aC++ compiler or use gcc as Steven said.

>may I know how to solve this problem where the "unknown input file type" 

Now we know why, you created an executable and not a shlib.

[Steven Schweda]

> (Bundled) cc: warning 922: "-b" is unsupported in the bundled compiler,
> ignored.

   My next question would be why, if '"-b" is unsupported', is its use
"ignored", and not a fatal error?  What's desirable in getting output
which is clearly not what was requested?  Is that better than none?  All
that behavior did here was confuse things.

[Dennis Handly]

> if '"-b" is unsupported', is its use "ignored", and not a fatal error?

Because all unsupported options are ignored as warnings.  Probably since most of them aren't as serious as this.

[MissX]

Hi Steven and Dennis,

Thank you so much for all the replies. All this while I can't reply to you because my server was down for a few weeks.

>> You can't build shlibs with the bundled C compiler.  You must purchase a C/aC++ compiler or use gcc as Steven said.

Now that it's back up, I tried to install both gcc and gnu one at a time. However, the same problem occurred.

(Bundled) cc: warning 922: "-b" is unsupported in the bundled compiler, ignored.

I have set the environment path for both gcc and gnu but to no avail.

[Steven Schweda]

> [...] I tried to install both gcc and gnu one at a time. [...]

   What, exactly, did you try to install?  (How, exactly?)

> [...] As usual, showing actual commands with their actual output can
> be more helpful than vague descriptions or interpretations.

   Still true.

   And, after you tried to install (some version of) GCC (which you
obtained from somewhere), did a "gcc" command work properly?

> I have set the environment path for both gcc and gnu but to no avail.

> [...] As usual, showing actual commands with their actual output can
> be more helpful than vague descriptions or interpretations.

   Still true.

> [...] However, the same problem occurred.
>
> (Bundled) cc: warning 922: "-b" is unsupported in the bundled compiler,
> ignored.

> [...] As usual, showing actual commands with their actual output can
> be more helpful than vague descriptions or interpretations.

   Still true.

   When _I_ run "./configure", the script says things like:

[...]
checking for gcc... gcc
[...]

which suggests that, if you have installed GCC (properly), and "gcc" is
on your PATH, then "configure" will try to use "gcc" in preference to
"cc".  Did you start with a clean sirectory, or are you still using
"(Bundled) cc" because you haven't run "configure" since you "tried to
install" GCC?

> [...] As usual, showing actual commands with their actual output can
> be more helpful than vague descriptions or interpretations.

   Still true.

   My psychic powers are too weak to tell me what you did and what
happened when you did it, and I'm too lazy to try to guess.  If you want
help, then you may need to provide some actual information.

[MissX · Accepted solution]

Thank you  to Steven, TTr and Dennis for all your help.

The problem is solved :D. Here is what we do:

1) uninstall the previous gnu-make

2) install gcc, gettext, libiconvi.

3) export PATH of gcc to environment variables

    eg: export PATH=$PATH:/usr/local/bin

         export PATH=$PATH:/usr/local/lib

4) gunzip the unixODBC file

5) then un-tar the file.

6) cd to the unixODBC folder

7) # ./configure

  Note: In case u want it to install in specific path, use

 eg: ./configure --prefix=/THE_WANTED_PATH

8) # make

9) # make install

[Steven Schweda]

>     eg: export PATH=$PATH:/usr/local/bin

   Ok.

>          export PATH=$PATH:/usr/local/lib

   I would not expect that to be useful.

> 4) gunzip the unixODBC file
> 5) then un-tar the file.

> > [...] As usual, showing actual commands with their actual output can
> > be more helpful than vague descriptions or interpretations.
>
>    Still true.

   I know that that's what the Web page says, but you can do it in one
step without wasting disk space on the ".tar" file:

      gzip -dc unixODBC-2.3.4.tar.gz | tar xf -

(One problem with "tar xfv" is that error messages can easily scroll
away and get lost.)

> 8) # make
>
> 9) # make install

   What could go wrong?