Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P
------------------------------

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

Got it and it seems to be working.  Thanks!  Any thoughts on this one?

[mmetts@crcoacs1 ~]$ psql
Could not load program psql_64:
Symbol resolution failed for psql_64 because:
       Symbol _GLOBAL__AIXI_libxml2_so (number 205) is not exported from dependent
         module /usr/lib/libxml2.a[libxml2.so.2].
       Symbol _GLOBAL__AIXD_libxml2_so (number 206) is not exported from dependent
         module /usr/lib/libxml2.a[libxml2.so.2].
Examine .loader section symbols with the 'dump -Tv' command.

…but this works:

[mmetts@crcoacs1 ~]$ LIBPATH= psql
psql: FATAL:  database "mmetts" does not exist

…here's what's in LIBPATH otherwise:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...and not to be tedious but here's vim with the same problem as git:

[mmetts@crcoacs1 ~]$ vim
Could not load program vim:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

Thanks again,
Mike

------------------------------
Michael Metts
------------------------------

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

libxml2 is another library that comes with AIX base as well as from Toolbox, just like libiconv.
As mentioned above we are still fixing these issues. So it's not yet complete. Till then one has to run those without LIBPATH.

------------------------------
Ayappan P
------------------------------

Original Message:
Sent: Tue June 16, 2020 01:35 PM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Got it and it seems to be working.  Thanks!  Any thoughts on this one?

[mmetts@crcoacs1 ~]$ psql
Could not load program psql_64:
Symbol resolution failed for psql_64 because:
       Symbol _GLOBAL__AIXI_libxml2_so (number 205) is not exported from dependent
         module /usr/lib/libxml2.a[libxml2.so.2].
       Symbol _GLOBAL__AIXD_libxml2_so (number 206) is not exported from dependent
         module /usr/lib/libxml2.a[libxml2.so.2].
Examine .loader section symbols with the 'dump -Tv' command.

…but this works:

[mmetts@crcoacs1 ~]$ LIBPATH= psql
psql: FATAL:  database "mmetts" does not exist

…here's what's in LIBPATH otherwise:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...and not to be tedious but here's vim with the same problem as git:

[mmetts@crcoacs1 ~]$ vim
Could not load program vim:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

Thanks again,
Mike

------------------------------
Michael Metts

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon
------------------------------

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

Just to be complete, there's also this with curl:

[mmetts@crcoacs1 ~]$ curl
Could not load program curl:
Could not load module /usr/lib/libcurl.a(libcurl.so.4).
Dependent module /usr/lib/libgssapi_krb5.a(libgssapi_krb5.so) could not be loaded.
Member libgssapi_krb5.so is not found in archive
Could not load module curl_64.
Dependent module /usr/lib/libcurl.a(libcurl.so.4) could not be loaded.
Could not load module .

... Yes, if there's a way to patch this in the field so to speak with ldedit, please advise.  Thanks.

------------------------------
Michael Metts
------------------------------

Original Message:
Sent: Wed June 17, 2020 09:34 AM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

I don't think there is any tool to edit the library search path of executables, atleast in AIX.
Linux has chrpath but that also has it's own limitation.

------------------------------
Ayappan P
------------------------------

Original Message:
Sent: Wed June 17, 2020 09:34 AM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

A general question for users using LIBPATH in their environment and face these kind of issues.
Why not put "/opt/freeware/lib64:/opt/freeware/lib" before "/usr/lib" in the LIBPATH ? 
Are you facing any problems with that ?

We are making sure AIX base applications/programs don't get affected by Toolbox libraries present in /opt/freeware/lib. 
For example, in libiconv case, we copy the shared objects from /usr/lib/libiconv.a and put it inside /opt/freeware/lib/libiconv.a .
Same with krb5 related libraries as well.

------------------------------
Ayappan P
------------------------------

Original Message:
Sent: Wed June 17, 2020 10:24 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

I don't think there is any tool to edit the library search path of executables, atleast in AIX.
Linux has chrpath but that also has it's own limitation.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 09:34 AM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

if you are saying it's safe to do that then I suppose we can try it.  I just assumed it was not safe and I didn't want to crash Spectrum Scale or something else important by doing that.  there's also 3rd party things like SAS (it's also running on the machine in question) ... I'm not sure how it will react.  we have seen nasty surprises there.  I have to hack the GNU file command out of existence in /opt/freeware/bin for SAS ... I know that's not a LIBPATH example but just the same.  Thanks.

------------------------------
Michael Metts
------------------------------

Original Message:
Sent: Wed June 17, 2020 10:47 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

A general question for users using LIBPATH in their environment and face these kind of issues.
Why not put "/opt/freeware/lib64:/opt/freeware/lib" before "/usr/lib" in the LIBPATH ? 
Are you facing any problems with that ?

We are making sure AIX base applications/programs don't get affected by Toolbox libraries present in /opt/freeware/lib. 
For example, in libiconv case, we copy the shared objects from /usr/lib/libiconv.a and put it inside /opt/freeware/lib/libiconv.a .
Same with krb5 related libraries as well.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 10:24 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

I don't think there is any tool to edit the library search path of executables, atleast in AIX.
Linux has chrpath but that also has it's own limitation.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 09:34 AM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

Is there script we need to run when we patch the system libiconv.a or krb5 libraries?

------------------------------
Edward Davignon
------------------------------

Original Message:
Sent: Wed June 17, 2020 10:47 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

A general question for users using LIBPATH in their environment and face these kind of issues.
Why not put "/opt/freeware/lib64:/opt/freeware/lib" before "/usr/lib" in the LIBPATH ? 
Are you facing any problems with that ?

We are making sure AIX base applications/programs don't get affected by Toolbox libraries present in /opt/freeware/lib. 
For example, in libiconv case, we copy the shared objects from /usr/lib/libiconv.a and put it inside /opt/freeware/lib/libiconv.a .
Same with krb5 related libraries as well.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 10:24 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

I don't think there is any tool to edit the library search path of executables, atleast in AIX.
Linux has chrpath but that also has it's own limitation.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 09:34 AM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

This is good question. Right now we do not update AIX toolbox libiconv/krb5 if system libiconv or krb5 are updated. 
The current implementation is for compatibility purpose and as mentioned by Ayappan we are fixing all such commands by hardcoding library path. 
That will be permanent solution.

------------------------------
SANKET RATHI
------------------------------

Original Message:
Sent: Wed June 17, 2020 03:24 PM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Is there script we need to run when we patch the system libiconv.a or krb5 libraries?

------------------------------
Edward Davignon

Original Message:
Sent: Wed June 17, 2020 10:47 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

A general question for users using LIBPATH in their environment and face these kind of issues.
Why not put "/opt/freeware/lib64:/opt/freeware/lib" before "/usr/lib" in the LIBPATH ? 
Are you facing any problems with that ?

We are making sure AIX base applications/programs don't get affected by Toolbox libraries present in /opt/freeware/lib. 
For example, in libiconv case, we copy the shared objects from /usr/lib/libiconv.a and put it inside /opt/freeware/lib/libiconv.a .
Same with krb5 related libraries as well.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 10:24 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

I don't think there is any tool to edit the library search path of executables, atleast in AIX.
Linux has chrpath but that also has it's own limitation.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 09:34 AM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------

So for now, it looks like we should reinstall libiconv when bos.rte.iconv is upgraded or installed.  Likewise for krb5-libs if krb5.client.rte is upgraded or installed.

For example:
yum reinstall krb5-libs

yum reinstall libiconv
Or
yum reinstall     /var/cache/yum/AIX_Toolbox/packages/libiconv-1.16-1.aix6.1.ppc.rpm
Or
rpm -ivh --force /var/cache/yum/AIX_Toolbox/packages/libiconv-1.16-1.aix6.1.ppc.rpm
yum check # update yum database​ after a manual rpm install

If applications are running on the system and these packages cannot safely be reinstalled, the spec files may show how to update only the affected libraries in /opt/freeware/lib*

See:

/usr/bin/grep -p '{AR} -x' libiconv-1.16-1.spec

/usr/bin/grep -p %post krb5-1.16.1-4.spec

------------------------------
Edward Davignon
------------------------------

Original Message:
Sent: Thu June 18, 2020 06:46 AM
From: SANKET RATHI
Subject: git 2.20.1 and conflict with libiconv

This is good question. Right now we do not update AIX toolbox libiconv/krb5 if system libiconv or krb5 are updated. 
The current implementation is for compatibility purpose and as mentioned by Ayappan we are fixing all such commands by hardcoding library path. 
That will be permanent solution.

------------------------------
SANKET RATHI

Original Message:
Sent: Wed June 17, 2020 03:24 PM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Is there script we need to run when we patch the system libiconv.a or krb5 libraries?

------------------------------
Edward Davignon

Original Message:
Sent: Wed June 17, 2020 10:47 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

A general question for users using LIBPATH in their environment and face these kind of issues.
Why not put "/opt/freeware/lib64:/opt/freeware/lib" before "/usr/lib" in the LIBPATH ? 
Are you facing any problems with that ?

We are making sure AIX base applications/programs don't get affected by Toolbox libraries present in /opt/freeware/lib. 
For example, in libiconv case, we copy the shared objects from /usr/lib/libiconv.a and put it inside /opt/freeware/lib/libiconv.a .
Same with krb5 related libraries as well.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 10:24 AM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

I don't think there is any tool to edit the library search path of executables, atleast in AIX.
Linux has chrpath but that also has it's own limitation.

------------------------------
Ayappan P

Original Message:
Sent: Wed June 17, 2020 09:34 AM
From: Edward Davignon
Subject: git 2.20.1 and conflict with libiconv

Ayappan,
I am glad to hear that your team has found a way to hardcod library paths in the loader section of applications, so LIBPATH won't have any effect on the library search path for that library.  This there a way to use ldedit, ld, or GNU ld to retrofit an existing binary to use this approach.  It might be useful for other teams that produce relocatable packages.  For example, DB2 is intended to have multiple instances installed on the same server and have the flexibility to install different versions of the binaries in each instance.

------------------------------
Edward Davignon

Original Message:
Sent: Tue June 16, 2020 01:13 PM
From: Ayappan P
Subject: git 2.20.1 and conflict with libiconv

Please update git to 2.20.2-1 to resolve this issue.
To avoid these kind of issues. we have recently taken the approach of hardcoding the library path of libiconv in the loader section of the applications which depends on libiconv library.  So LIBPATH won't have any effect on the library search path of libiconv.

dump -X64 -Hov /opt/freeware/bin/git

***Import File Strings***
INDEX          PATH                                    BASE                            MEMBER
0              /opt/freeware/lib64:/opt/freeware/lib:/usr/lib:/lib
1                                                                   libc.a                            shr_64.o
2                                                                   libpthreads.a             shr_xpg5_64.o
3                                                                   libintl.a                        libintl.so.8
4              /opt/freeware/lib                    libiconv.a                     libiconv.so.2
5                                                                   libz.a                             libz.so.1


------------------------------
Ayappan P

Original Message:
Sent: Tue June 16, 2020 11:39 AM
From: Michael Metts
Subject: git 2.20.1 and conflict with libiconv

Hello,

I would really like a better solution that I have for this issue.  When we run git on our AIX 7.1 machine we get this:

[mmetts@crcoacs1 ~]$ git
Could not load program git:
Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
Member libiconv.so.2 is not found in archive

...Unless we blank out LIBPATH so it will find libiconv.a in /opt/freeware/lib instead.  This leads to crappy global aliases on the system like this:

alias git='LIBPATH=/opt/freeware/lib:/usr/lib git'

...I truly think that in this day and age there has to be a better way to mix freeware with AIX.  Why can't git use the native AIX libiconv?  Couldn't these libraries have different names?  In any case, this is a very annoying problem.  

BTW, this is what the global LIBPATH looks like normally:

[mmetts@crcoacs1 ~]$ echo $LIBPATH
/home/db2inst1/sqllib/lib64:/home/db2inst1/sqllib/lib64/gskit:/home/db2inst1/sqllib/lib64/gskit:/usr/lib:/lib

...So it's not straight-forward to say that I should just have a blank one.  Does anyone have some helpful suggestions for a cleaner way to make all this stuff work together?

Thanks,
Mike

------------------------------
Michael L. Metts
Principal Data Engineer
CORNERSTONE RESEARCH
1000 El Camino Real, Suite 250
Menlo Park, CA 94025-4327
------------------------------