Re: FreeTDS build on AIX - No shared objects (.so) generated?

Looking at libtool changes it looks like newer libtool could help.

Yesterday I updated the libtool used to produce snapshort to last
stable version (2.4.6, previously was 2.4.2). This new version add an
extra --with-aix-soname option to the configure script.

Could you try to download the last snapshot, add a
"--with-aix-soname=srv4" or a "--with-aix-soname=both" to configure
command and try make + make install again?

Frediano


2015-09-22 22:41 GMT+01:00 Worman, Tyler <[email protected]>:
> The problem here with the copying is actually on the FreeTDS side. Sorry the first email might not have been clear.
>
> Similar things happen with UnixODBC. I'll email the maintainer just in case. Thanks!
>
> I'm not so sure it's is either package vs how AIX's libtool handles what configure produces.
> With both UnixODBC and FreeTDS the .so files are not copied from the .libs folders on AIX7.1.
>
> Wanted to document it here in case anyone else runs into a similar problem.
>
>    - Tyler
>
> -----Original Message-----
> From: FreeTDS [mailto:[email protected]] On Behalf Of Igor Korot
> Sent: Tuesday, September 22, 2015 8:59 AM
> To: FreeTDS Development Group
> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated?
>
> Hi,
>
> On Tue, Sep 22, 2015 at 12:17 AM, Worman, Tyler <[email protected]> wrote:
>> Following up on how to get the 64 bit version building correctly on AIX. I don't have autoreconf available to me so I couldn't try that test.
>>
>> Built 64-bit UnixODBC first. It's located in /home/tworman/local64/ in this example.
>>
>> export OBJECT_MODE=64
>> export PATH=$PATH:/usr/ccs/bin
>>
>> env CC=gcc CFLAGS="-maix64 -I/usr/local/include" AR_FLAGS="-X64 cru"
>> ARFLAGS="-X64 cru" ./configure --with-tdsver=8.0
>> --with-unixodbc=/home/tworman/local64 --prefix=/home/tworman/local64/
>>
>> make
>> make install
>>
>> The .so's still don't copy over on install. So I copied them from the .lib directory in the install to my lib directory and setup the links manually.
>>
>> In the new /local64/lib dir, I ran these...
>> ln -sf libct.so.4 libct.so
>> ln -sf libsybdb.so.5 libsybdb.so
>> ln -sf libtdsodbc.so.0 libtdsodbc.so
>>
>> That builds the symlinks for the .so files and then it seems to work just fine.
>>
>> Thanks again..
>
> You should send an email to unixodbc maintainer - Nick Gorham and ask him to fix the build. ;-)
>
> Thank you.
>
>>
>>     - Tyler
>>
>> -----Original Message-----
>> From: FreeTDS [mailto:[email protected]] On Behalf Of
>> Frediano Ziglio
>> Sent: Tuesday, September 15, 2015 2:47 PM
>> To: FreeTDS Development Group
>> Subject: Re: [freetds] FreeTDS build on AIX - No shared objects (.so) generated?
>>
>> 2015-09-15 18:39 GMT+01:00 Worman, Tyler <[email protected]>:
>>> Hi,
>>>  Trying to build FreeTDS (stable .95.19) on AIX 7100-03-05-1524. The .so files don't generate. Browsed online and tried a few suggested fixes for similar problems but no luck so far. Generated my own .so files from the .a that builds but it doesn't seem to work. Any advice?
>>>
>>> Using the following:
>>> ./configure --with-unixodbc=/usr/local/ --prefix=/home/tworman/local
>>> --with-tdsver=7.0 make make install
>>>
>>> Appears to complete but no .so files are generated in the directory /home/tworman/local/lib. I only get .a and .la files.
>>> I tested tsql that was built. It worked and connected to my MS SQL Server instance fine.
>>>
>>
>> tsql always works :)
>> It use static linking so one less issue to solve!
>> AIX is quite strange when it comes to shared libraries. The static library on AIX are not such different from static ones.
>>
>>> I then generated the .so from the .a with gcc -fpic -g -shared -o
>>> libtdsodbc.so libtdsodbc.a I verified my config using osql. It's fine until it gets to the actual connection and invoking isql (Unixodbc 32-bit).
>>
>> osql do you mean the utility in src/apps, right?
>>
>>> I tried the exact same .odbc.ini from a Linux box with a build of FreeTDS there and it works fine.
>>>
>>> The OSQL test:
>>> ./osql -S TEST -U accthere -P passwordhere
>>>
>>> That produces this but no dump.
>>> [IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on
>>> SQL_HANDLE_HENV failed
>>> [ISQL]ERROR: Could not SQLConnect
>>> sed: Cannot find or open file /tmp/osql.dump.51511686.
>>>
>>> If I do this instead, I still get no dump, and nothing is written to the file I specify.
>>> TDSDUMPCONFIG=stderr TDSDUMP=~/local/bin/temp ./osql -S TEST -U
>>> usernamhere -P passwordhere
>>>
>>
>> could be is not loading the driver so these environment are not used.
>>
>>> Thanks!
>>>
>>>      - Tyler
>>>
>>>
>>
>> It would be helpful to see the configure output to understand if something went wrong.
>>
>>>
>>>
>>>
>>>
>>> Semi-unrelated try of 64 bit build (even though UnixODBC is compiled with 32bit types).
>>> export OBJECT_MODE=64
>>> export CFLAGS=-maix64
>>> export LIBPATH=/usr/local/lib
>>> export LD_LIBRARY_PATH=/usr/local/lib export AR_FLAGS="-X64 cru"
>>> export ARFLAGS="-X64 cru"
>>> ./configure --with-tdsver=7.0 --with-unixodbc=/usr/local
>>> --prefix=/home/tworman/local
>>>
>>> Configure is fine but build of this fails with:
>>> Making all in .
>>>   CC       odbc.lo
>>> odbc.c: In function '_SQLRowCount':
>>> odbc.c:4630: warning: visibility attribute not supported in this configuration; ignored
>>>   CC       connectparams.lo
>>> connectparams.c:96: error: static declaration of
>>> 'SQLGetPrivateProfileString' follows non-static declaration
>>> /usr/local/include/odbcinst.h:210: error: previous declaration of
>>> 'SQLGetPrivateProfileString' was here
>>
>> Is quite expected, is finding the declaration but not the function.
>> Trying to remove the odbcinst.h should make it compile.
>> Better to have a 64 bit unixODBC !
>>
>>> make: The error code from the last command is 1.
>>> Stop.
>>> make: The error code from the last command is 1.
>>> Stop.
>>> make: The error code from the last command is 2.
>>> Stop.
>>> make: The error code from the last command is 1.
>>> Stop.
>>> make: The error code from the last command is 1.
>>> Stop.
>>>
>>> Not sure if this is really the path I should go down. This seems like
>>> I just have multiple libraries defining SQLGetPrivateProfileString
>>> but I only see one in my library path. That is the one from unixodbc
>>> at /usr/local/include/
>>
>> If you have autoconf installed in the system you can try with
>>
>>   autoreconf -if
>>
>> command before configure to see if you can get a working libtool.
>>
>> Or I can try to make a distribution from a recent system and send to you to try a new libtool.
>>
>> Frediano
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>> **********************************************************
>> Electronic Mail is not secure, may not be read every day, and should
>> not be used for urgent or sensitive issues
>>
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds