> On Fri May 18 13:59:32 2012, n4zmz wrote:
> > After installing Informix 11.50.FC9DE on OSX Lion 10.7.4, a number
> of
> > issues came up in building. The first was that the Makefile.PL
> included
> > both -arch x86_64 and -arch i386. This keeps everything from
> linking.
> > Removing the "-arch i386" from the Makefile corrects this issue.
> The
> > second issue was that the location of DBI is not in the standard
> > locations, but is found using the variable $(DBI_INSTARCH_DIR).
> After
> > correcting these two issues, it will compile but not link due to the
> > Informix library libifasf.a not being compiled as x86_64.
> >
> > Here is the output of perl -V
> > perl -V
> > Summary of my perl5 (revision 5 version 12 subversion 3)
> configuration:
> >
> > Platform:
> > osname=darwin, osvers=11.0, archname=darwin-thread-multi-2level
> > uname='darwin doublemagnum.apple.com 11.0 darwin kernel version
> > 11.0.0: wed dec 22 11:00:23 pst 2010; root:xnu-
> 1699.18.1~1release_x86_64
> > x86_64 '
> > config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe
> -Dldflags=
> > -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none
> > -Dcc=llvm-gcc-4.2'
> > hint=recommended, useposix=true, d_sigaction=define
> > useithreads=define, usemultiplicity=define
> > useperlio=define, d_sfio=undef, uselargefiles=define,
> usesocks=undef
> > use64bitint=define, use64bitall=define, uselongdouble=undef
> > usemymalloc=n, bincompat5005=undef
> > Compiler:
> > cc='llvm-gcc-4.2', ccflags ='-arch x86_64 -arch i386 -g -pipe
> > -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector
> > -I/usr/local/include',
> > optimize='-Os',
> > cppflags='-g -pipe -fno-common -DPERL_DARWIN
> -fno-strict-aliasing
> > -fstack-protector -I/usr/local/include'
> > ccversion='', gccversion='4.2.1 (Based on Apple Inc. build 5658)
> > (LLVM build 2335.15.00)', gccosandvers=''
> > intsize=4, longsize=8, ptrsize=8, doublesize=8,
> byteorder=12345678
> > d_longlong=define, longlongsize=8, d_longdbl=define,
> longdblsize=16
> > ivtype='long', ivsize=8, nvtype='double', nvsize=8,
> Off_t='off_t',
> > lseeksize=8
> > alignbytes=8, prototype=define
> > Linker and Libraries:
> > ld='llvm-gcc-4.2 -mmacosx-version-min=10.7', ldflags ='-arch
> x86_64
> > -arch i386 -fstack-protector -L/usr/local/lib'
> > libpth=/usr/local/lib /usr/lib
> > libs=-ldbm -ldl -lm -lutil -lc
> > perllibs=-ldl -lm -lutil -lc
> > libc=, so=dylib, useshrplib=true, libperl=libperl.dylib
> > gnulibc_version=''
> > Dynamic Linking:
> > dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
> > cccdlflags=' ', lddlflags='-arch x86_64 -arch i386 -bundle
> > -undefined dynamic_lookup -L/usr/local/lib -fstack-protector'
> >
>
>
> I am not sure what DBD::Informix is supposed to do about the
> dual-architecture bit. The Perl configuration contains:
>
> ccflags ='-arch x86_64 -arch i386 ...'
>
> That is one of the flags the DBD::Informix therefore uses. I've never
> seen this problem because I've never tried building using a
> system-provided Perl -- I use DBD::Informix 2011.0612 on Mac OS X
> 10.7.4
> routinely (to the extent DBD::Informix is developed, it is the main
> development platform). But I use my own build of Perl so I can
> install
> what I like without any chance of messing up the system installation
> of
> Perl, which is usually retrograde by my standards. (I'm using 5.14.2,
> though that's a recent step from 5.14.1 which I'd been using for a
> long
> time.)
>
> I'm not clear what you are recommending as a fix to this problem (if
> you're recommending anything). I could try looking for and deleting
> '-arch i386' on a Mac since DBD::Informix will not have 32-bit support
> available. There are enough other ad hoc platform patches lurking
> around that one more really won't matter very much. I think that a
> consequence of that change would be that if the system felt
> constrained
> to run the 32-bit version of Perl, then DBD::Informix would not be
> available. I doubt if that's a serious limitation, but it would
> presumably need to be noted. IBM does not provide dual-architecture
> CSDK libraries.
>
>
>
> You also mention:
>
> > The second issue was that the location of DBI is not in the standard
> > locations, but is found using the variable $(DBI_INSTARCH_DIR).
>
>
> In the Makefile generated on my system, I found:
>
> # --- This section was generated by DBI::DBD::dbd_postamble()
> DBI_INSTARCH_DIR=/Users/jleffler/Perl/v5.14.2/lib/perl5/site_perl/5.14.2/darwin-
> 2level/auto/DBI
> DBI_DRIVER_XST=/Users/jleffler/Perl/v5.14.2/lib/perl5/site_perl/5.14.2/darwin-
> 2level/auto/DBI/Driver.xst
>
>
> So, your problem is that the name established for DBI_INSTARCH_DIR is
> incorrect?
>
> Since that information comes direct from the code provided by DBI, I'm
> not sure whether the problem is in DBD::Informix or in DBI. The
> DBD::Informix Makefile.PL contains no reference to DBI_INSTARCH_DIR;
> the
> DBI::DBD::dbd_postamble() function is provided by DBI.
>
> What value did you end up setting DBD_INSTARCH_DIR to? I wonder how
> DBI
> should have know to set it to that...
>
> On the subject of libifasf.a, then:
>
> (1) I would expect DBD::Informix to be using the dylib files.
> However,
> I see that my build does not use them. I guess I'm going to have to
> track down what's wrong there.
> (2) I'm surprised that libifasf.a is not a 64-bit build; very
> surprised.
> (3) On my machine, the 11.50.FC6, the library consisted solely of
> x86_64
> (only) variables. Likewise with 11.70.FC2. I don't have 11.50.FC9DE
> on
> hand, but it would be surprising to find it was different. OTOH, you
> ran into a problem.
>
> ...Some tracking on shared objects...
>
> The value of Perl $Config{dlext} is 'bundle'; it is the extension used
> on shared objects created by Perl. Apparently, the code which tracks
> and maps ESQL/C libraries should be using $Config{so} (which contains
> 'dylib') on Mac OS X instead of (or possibly as well as)
> $Config{dlext}.
>
>
> If you're interested in trying out a fix, then the c.patch file
> attached
> contains two deltas since the 2011.0612 release, minus the copyright /
> version number parts. One protects against $INFORMIXDIR path names
> containing Perl regex metacharacters ('+' was the specific problem);
> the
> other is the fix to look for files with the $Config{so} extension. It
> worked for me, and will be properly acknowledged when it is formally
> checked in.
>
> Harking back to the libifasf.a file being 32-bit not 64-bit...Did you
> by
> any chance install a 32-bit CSDK at some point? That would be CSDK
> 3.50.UC9 (for some digit 1..9 or thereabouts). If so, it might have
> overwritten the 3.50.FC9DE CSDK library. OTOH, this is a pretty big
> stretch; that would have damaged other libraries too.
>
> Unless I find or get a full name and email, the credit will be:
>
> 2012-05-19: Use $Config{so} as well as $Config{dlext} searching for
> ESQL/C
> libraries. Ticket 77286 at rt.cpan.org, submitted by
> n4zmz.
>
> Thoughts, feedback - both are welcome.
>
> I would like to know where DBI is installed on your machine, please.
As for what is installed, I only installed the iif.11.50.FC9DE.macosx64.dmg file. No other CSDK.
Here is the INC portion of the generated Makefile:
INC => q[ -I/Applications/IBM/informix/incl/esql -I$(INSTALLARCHLIB)/auto/DBI -
I$(INSTALLSITEARCH)/auto/DBI -I$(INSTALLVENDORARCH)/auto/DBI -
I$(SITEARCHEXP)/auto/DBI]
Here is the DBI_INSTARCH_DIR
DBI_INSTARCH_DIR=/System/Library/Perl/Extras/5.12/darwin-thread-multi-2level/auto/DBI
Fixing the INC to point to DBI_INSTARCH_DIR instead of all of the INSTALLARCHLIB, etc.
New INC line:
INC = -I/Applications/IBM/informix/incl/esql -I$(DBI_INSTARCH_DIR)
Here is the error for the link:
llvm-gcc-4.2 -mmacosx-version-min=10.7 -arch x86_64 -bundle -undefined
dynamic_lookup -L/usr/local/lib -fstack-protector Informix.o dbdimp.o dbdattr.o sqltoken.o
sqltype.o ixblob.o odbctype.o kludge.o link.o esqlcver.o esqlc_v6.o -
L/Applications/IBM/informix/lib -L/Applications/IBM/informix/lib/esql -lifsql -lifasf -lifgen -
lifos -lifgls -framework DirectoryService /Applications/IBM/informix/lib/esql/checkapi.o -lifglx
-o blib/arch/auto/DBD/Informix/Informix.bundle \
\
ld: warning: ignoring file /Applications/IBM/informix/lib/libifasf.a, file was built for archive
which is not the architecture being linked (x86_64)
chmod 755 blib/arch/auto/DBD/Informix/Informix.bundle
The Patch did not appear to change the behavior.
