Compiling 64 bit binaries on AMD64

I have various AMD64 cpu machines which I intend to us as nodes in an ethernet cluster (to use MPI) WHEN I can get my programmes to compile to 64 bit code.
I enclose the output from make for a simple molecular dynamics simulation:
CC -g -I/usr/include/amd64 -I/usr/include -xarch=amd64 -64 -c moldyn.cpp
CC: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
"physics.h", line 337: Warning: tau hides Slab::tau.
1 Warning(s) detected.
CC -g -I/usr/include/amd64 -I/usr/include -xarch=amd64 -64 -c gasdev.cpp
CC: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
CC -g -I/usr/include/amd64 -I/usr/include -xarch=amd64 -64 -c ran2.cpp
CC: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
CC -g -I/usr/include/amd64 -I/usr/include -xarch=amd64 -64 -c phys.cpp
CC: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
"physics.h", line 337: Warning: tau hides Slab::tau.
1 Warning(s) detected.
CC -g -I/usr/include/amd64 -I/usr/include -xarch=amd64 -64 -c bessk1.cpp
CC: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
CC -g -I/usr/include/amd64 -I/usr/include -xarch=amd64 -64 -c bessi1.cpp
CC: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
CC -64 -o moldyn moldyn.o gasdev.o ran2.o phys.o bessk1.o bessi1.o
CC: Warning: Option -64 passed to ld, if ld is invoked, ignored otherwise
ld: fatal: file moldyn.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to moldyn
*** Error code 1
make: Fatal error: Command failed for target `moldyn'
how can I follow up and correct the ld error? I have spent several days combing through the SUNWspro documentation. I would greatly appreciate any hints

When linking, you need to use a -xarch option compatible with the option used for compiling. And in case it isn't obvious, all the object files in the link must have been compiled with compatible -xarch options. (You can't mix 32-bit and 64-bit object files in one program, for example.)
On x86 platforms, the default value for -xarch is 386, meaning (32-bit) Pentium III. By default, the CC (or cc) driver will pass 32-bit system libraries to the linker. You have to tell CC (or cc) that you want to link a 64-bit program.
In your case, use -xarch=amd64 on every CC and cc command used in building the program, compiling and linking.
For more complete information, refer to the C++ Users Guide.

Similar Messages

  • Visual Studio compiling 64 Bit Plugin for InDesign Server CS5

    Hello guys,
    Again I have a problem compiling 64 bit plugins, but this time in windows environments, the 32 bit compiling works fine (also on 64 bit machines). The first thing I've done was creating a new project configuration for 64 bit environments copying the 32 bit settings. Now I changed the precompiled libraries to use the 64 bit ones and changed the output directories. After that the compilation process completed without errors, but the resource files have not been copied to the output directory (the directory for them has been created, but it remains empty). Adding the created plugin into the servers directory ends up with a server message that the plugin could not be recognized. Have I missed something that is necessary for compiling 64 bit plugins?
    I'm using the 64 Bit Developer Version of the indesign server CS5. The operating system is a Windows Server 2008 x64 R2 with Visual Studio 2008.
    Thanks!
    P.S. a plugin compiled with 32 bit settings (including 32 bit libraries) also works for the 64 bit version of the server, so does it make any difference if I'm using 32 bit or 64 bit libraries?

    The libraries were all correct (all using 64-bit).  The problem was a pathing issue.  libxml2 needs iconv.dll, but it couldn't find the 64-bit version that I built.  Once it found it, everything worked correctly.
    The funny thing about depends.exe is that it isn't right all the time.  For example, if you open one of the 64-bit .aip files that ships with Illustrator (rename it to .dll first), you'll see what I'm talking about.  It complains that you're mixing x86 and x64 CPU types, even though you're not.
    The program I used to discover my issue is Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx).  I've been using it for years and love it.

  • Spotify 1.0.11 beta for Linux is out, with 32-bit binaries!

    Hello Linux users!
    Today we've released Spotify client version 1.0.11 for Linux. There are some big changes in this version, and it's still considered to be a beta release, and will be in beta until the items in the "known issues" list below are resolved. If you want to try out this version, installation instructions remain the same as for the other betas:
    echo deb http://repository.spotify.com testing non-free | sudo tee /etc/apt/sources.list.d/spotify.list
    sudo apt-get update
    sudo apt-get install spotify-client
    or if you have a previous version installed, simply:
    sudo apt-get upgrade
    Since the previous public release (version 1.0.9), we've made the following Linux-specific changes:
    32-bit binaries are now available! Now users on i386 systems can try out the 1.x betas as well. Please reply to this thread with any technical problems that you encounter on that architecture.
    libnotify is now an suggested package dependency. If you don't have that library installed, this feature will simply be unavailable.
    Updated application icon in the spotify.desktop entry
    GPU acceleration is disabled (see below)
    This build ships with the following limitations, of which we are still currently working on:
    Proper dbus support for MPRIS MediaPlayer2
    There is no application menu
    It is not possible to re-enable GPU acceleration through the settings
    Important: regarding GPU acceleration, this is now completely disabled in the client, and we do not yet have a way to enable it in the preferences. This change was originally made in Chromium for Linux, but since the Spotify client uses CEF, we inherited this change from them. According to the Launchpad bug report, faulty GPU driver support was the single largest cause of crashes for Chromium on Linux (this graph shows how Chromium crashes on Linux have dramatically decreased after the setting was changed).
    Depending on your hardware and GPU drivers, this change is either going to be a big annoyance for you or a huge blessing. For our users who experienced frequent and strange crashes with the client, this change will probably greatly increase client stability. For other users with certain video cards, scrolling performance and redraw rates may be noticeably choppier. Some users won't notice anything at all.
    The obvious solution here is that our Linux client needs a toggle to manually re-enable this feature in the settings. Exposing this feature is not as straightforward as you might believe, or else we would have done it already. ;) However, we're working on a way to do just that, and hopefully will have something in place for the next beta release.

    nikreiman wrote:
    blubbo wrote:
    Thanks for your continued support for Linux! It _is_ appreciated! :) Any chance the queing over Connect is gonna be looked at soon? The windows client seems to only be able to queue one song. If there already is one song in the queue nothing happens when you try to add another (except for the weird reshuffling that happens whenever you touch the queue). And if there are more than 1 song queued, the windows client removes all but the first one. From Android it works almost always. This is the only complaint I have with the Linux version but it's kind of a deal breaker when using it soley as an headless music player.This sounds like a bug, and a non Linux specific one at that. I'll look into this, however there are some changes to the player stack which will also effect connect that we are just rolling out. These changes will not require a client update, so there is a chance that you'll notice this behavior "magically" fix itself in the upcoming weeks. Anyways this is not a known limitation from our end for Linux users, we will investigate this bug.Good. Controlling -> PlayingWindows -> Android: Queing in itself works. But the queue gets cleared when the first song in it starts playing.Windows -> Linux: As explained above.Android -> Windows: Queing in itself works. But the client shows information for the song directly after the queued songs.Android -> Linux: Queing in itself works. But the client shows information for the song directly after the queued songs. So ... abrakadabra? :)

  • Downloading compiled FPGA bit file to target

    Hello.
    I'm trying to use multiple FPGA VIs in a same project, same target.
    But, currently the Labview force me to re-compile when I want to run different FPGA VI in same project.
    Even after compiling two FPGAs, the Labview program attempts to re-compile when I trying to run differnt FPGA VI.
    So I refered http://zone.ni.com/reference/en-XX/help/371599G-01/lvfpgahelp/compiling_fpga_vis_howto/ to download compiled FPGA bit file to the target to transit to another FPGA VI.
    However, still the Labview program trying to re-compile the FPGA VI when I click RUN on the VI after downloading compiled VI to the flash of the target.
    How can I solve this problem?
    P.S.:
    I checked off the option of the build specification that the FPGA VI does not automatically run when it is loaded to target and the target switch is on.

    Are you sharing VIs between the two top-level VIs?
    If they have any conditional disable structures with different settings then the sub-VIs will be marked as changed when opening the top-level VI  for your second target.
    Do you need to run the code in interactive mode or can you simply compile a bitfile and use that instead.  That was the compilation requirement disappears.
    I agree though that LVs rush to mark VIs as changed is a problem for interactive FPGA mode.
    Shane.
    Say hello to my little friend.
    RFC 2323 FHE-Compliant

  • How to compile 64-bit PHP 5?

    Hi
    Since having a nice 64-bit machine I thought I would installed MySQL 5.0.16 64-bit, only one problem PHP 5.1.1 will not compile with the 64-bit MySQL.
    I realised after a bit of reading that I am trying to compile a standard 32-bit PHP, when it should be 64-bit also.
    Are there Apple 64-bit libraries to allow me to compile a 64-bit PHP?
    If so how, I am no unix geek unfortunatly just picked up basics from guides such as on http://www.phpmac.com/.

    hi thanks for the quick responce cheers.

  • Problems compiling 64-bit version of openldap-2.2.29

    Anyone try to build a 64-bit version of openldap-2.2.29? We tried and the assembler is giving us a problem:
    cc -mr -Qn -xstrconst -xO2 -xtarget=opteron -xarch=amd64 -I../../include -I../../include -I/opt/TWWfsw/libdb42/include -I/opt/TWWfsw/libsasl21/include -I/opt/TWWfsw/libopenssl097/include -DLBER_LIBRARY -c decode.c  -KPIC -DPIC -o .libs/decode.lo
    Assembler: decode.c
            "/tmp/IAA2jaONn", line 208 : Illegal register: "icc"
            "/tmp/IAA2jaONn", line 208 : Syntax error
            Near line: "    orq        %icc,%r13                            ;/ line : 80"
            "/tmp/IAA2jaONn", line 209 : Illegal register: "icc"
            "/tmp/IAA2jaONn", line 209 : Syntax error
            Near line: "    movq       %icc,%r8                             ;/ line : 82"
    cc: ube failed for decode.c
    gmake: *** [decode.lo] Error 1The problem only occurs with -xO2. With -xO1, there is no error. Looking at the assembly file:
    .CGF.77:
            shlq       $8,%r13                              ;/ line : 79
            orq        %icc,%r13                            ;/ line : 80
            movq       %icc,%r8                             ;/ line : 82
            andq       $128,%r8                             ;/ line : 82
            testq      %r8,%r8                              ;/ line : 82
            je         .CG11.79                             ;/ line : 82

    This is with Studio 11 on Solaris 10/x86:
    $ uname -a
    SunOS [host] 5.10 Generic_Patch i86pc i386 i86pc
    $ cc -V
    cc: Sun C 5.8 Patch 121016-02 2006/03/31

  • Installation 11.1.2 (32 bit binaries) on win 64 bit server

    Hi,
    I downloaded 11.1.2 and extarcted in one folder.
    double click on InstallTool.cmd---> error
    "windows cannot find 'D:Hyperion11.1.2\jre\winAMD64\1.6.0\bin\java'. Make sure you typed the name correctly and try again. to search for a file, click the stsrt button, and then click search"
    Any suggestion where i made mistake.
    Server 2003 R2 SP1 x64
    Is this related to SP2
    While same is working with another server win 2003 SP2 R2.
    Regards
    Kumar
    Edited by: Kumar 1 on May 3, 2011 1:39 AM

    I am getting the below error while installing Oracle Enterprise Performance Management (11.1.2.1.0)- 32 bit machine
    Exception in thread "main" java.lang.NoClassDefFoundError: and
    Caused by : java.lang .ClassNotFoundException: and
    at java.net.URLClassLoader$1.run<URLClassLoader.java:200>
    at java.security.AccessController.doPrivileged<Native Method>
    at java.net.URLClassLoader.findClass<URLClassLoader.java:188>
    at java.Lang.ClassLoader.loadClass<ClassLoader.java:307>
    at sun.misc.Launcher$AppClassLoader.loadClass<Launcher.java:301>
    at java.lang.ClassLoader.LoadClass<ClassLoader.java:252>
    at java.lang.ClassLoader.LoadClassInternal<ClassLoader.java:320>
    Could not find the main class:

  • How 32-bit binaries are told to access the proper multilibs (lib32-*)

    Hello,
    I'm curious -- how is Arch prepared/configured to automatically direct a closed/static binary to the appropriate 32-bit library in an x86_64 system?  I would guess there are some automatic changes when a 32-bit binary is invoked.  Maybe some temporary binds are put in place, but where is this defined and how does it work?  Perhaps we can use some content and discussion in this thread to spruce up the related wiki page:  https://wiki.archlinux.org/index.php/Multilib_Project [+]
    Background and some related reading I was looking through:
    https://wiki.archlinux.org/index.php/Ar … _Arch64.3F [+]
    https://wiki.archlinux.org/index.php/Ar … nvironment [+]
    -velu

    Just dumping additional related material for review.  Feel free to dump more!  Trying to learn here, but have no mentor or reliable sources.  Possibly generate some interest in other newbies.
    (This is all just unverified stuff, not strictly compatible with how 32-bit has been prepared on 64-bit Arch.)
    basics
    http://en.wikipedia.org/wiki/X86-64#Linux [+]
    example on a debian system
    http://www.debian-administration.org/ar … _GNU/Linux [+]
    gentoo's chroot guide
    http://www.gentoo.org/proj/en/base/amd6 … t=1&chap=2 [+]
    arch's chroot info, no directly related to linking libs
    https://wiki.archlinux.org/index.php/Chroot [+]
    general info on libraries, nothing about switching between long-mode and 32-bit
    http://tldp.org/HOWTO/Program-Library-H … aries.html [+]
    and of course man ldconfig, ldd, ld.so, and elf

  • I am running an old legacy Sun server (Solaris10 U7) and need a compiled 64 bit version of liblpSolve55. I don't have studio or R, and very limited knowledge of C.

    Can anyone help, or point me in the correct direction ?
    I have tried downloading source and compiling but get all sorts of gcc compiler errors, and as I'm not conversant with compilers, C or anything similar, need a precomiled version of this library.
    Any help very gratefully received.
    Charles Richards

    That's a comment in the file. It has no effect at all.

  • [SOLVED] gcc-multilib vs cross32-gcc

    What is the difference between gcc-multilib from http://supraverse.net/arch and cross32-gcc from community repo? I currently use gcc-multilib. If cross32-gcc provides the same functionality, how do I use this gcc for compiling 32-bit binaries.
    I use gcc-multilib mainly to compile grub-legacy, grub2 for bios and grub2 for i386 UEFI. Can anyone try compiling grub2-efi-bzr (with _EFI_ARCH=i386 in the PKGBUILD) in Arch64 using cross32-gcc. I maintain that package and i am willing to modify the PKGBUILD to use cross32-gcc in case of cross-compiling. Thanks in advance.
    Last edited by skodabenz (2011-01-30 19:37:06)

    Marenz wrote:
    RetroX wrote:
    cross32-gcc is actually just the 32-bit gcc package for 64-bit platforms.  gcc-multilib includes just about every architecture, which is why it's 68 MB instead of about16.
    Also, the gcc-multilib package is neat, but it doesn't seem to be maintained very well.  It doesn't actually specify that it conflicts with the regular GCC, and it seems to be out of date currently.
    Well, yes, I don't have the time and right now not even the hardware to update it (my 64bit desktop is pretty far away right now), sorry about that.
    If anyone is willing to step in here, be my guest. Just provide me with the packages. I can also offer write access to the related git repositroy with the PKGBUILDs.
    --Marenz
    Ah, that's fine.  I guess that I'll just use the cross32-gcc.
    And I didn't notice that this topic was a week old. D:
    Sorry about that.
    Last edited by RetroX (2010-08-21 16:07:45)

  • Max number of file descriptors in 32 vs 64 bit compilation

    Hi,
    I compiled a simple C app (with Solaris CC compiler) that attempts to open 10000 file descriptors using fopen(). It runs just fine when compile in 64-bit mode (with previously setting �ulimit �S -n 10000�).
    However, when I compile it in 32-bit mode it fails to open more than 253 files. Call to system(�ulimit �a�) suggests that �nofiles (descriptors) 10000�.
    Did anybody ever see similar problem before?
    Thanks in advance,
    Mikhail

    On 32-bit Solaris, the stdio "FILE" struct stores the file descriptor (an integer) in an 8-bit field. WIth 3 files opened automatically at program start (stdin, stdout, stderr), that leaves 253 available file descriptors.
    This limitation stems from early versions of Unix and Solaris, and must be maintained to allow old binaries to continue to work. That is, the layout of the FILE struct is wired into old programs, and thus cannot be changed.
    When 64-bit Solaris was introduced, there was no compatibility issue, since there were no old 64-bit binaries . The limit of 256 file descriptors in stdio was removed by making the field larger. In addition, the layout of the FILE struct is hidden from user programs, so that future changes are possible, should become necessary.
    To work around the limit, you can play some games with dup() and closing the original descriptor to make it available for use with a new file, or you can arrange to have fewer than the max number of files open at one time.
    A new interface for stdio is being implemented to allow a large number of files to be open at one time. I don't know when it will be available or for which versions of Solaris.

  • SS10 on Solaris10/AMD64: issue compiling for AMD64 (linking fails)

    Hello,
    I've just installed SS10 trial and while trying our middleware stack compilation, I've found that CC/cc are not able to create AMD64 binary on my Sol10 setup. The command (test-case):
    cc -xarch=amd64 hello.c
    fails with:
    ld: fatal: file /usr/ucblib/libucb.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libsocket.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libnsl.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libelf.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libaio.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libc.so: wrong ELF class: ELFCLASS32
    ld: fatal: File processing errors. No output written to a.out
    Is there any workaround for this?
    Thanks,
    Karel Gardas

    TV is already on! :-)
    OK, hello.c or now foo.c is just simple C program, I've had LD_LIBRARY_PATH defined, but even when I unset it, the result is still the same. I do not have LD_PRELOAD defined. Let's see shell session:
    -bash-3.00$ echo $LD_PRELOAD
    -bash-3.00$ echo $LD_LIBRARY_PATH
    -bash-3.00$ cc -xarch=amd64 foo.c
    ld: fatal: file /usr/ucblib/libucb.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libsocket.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libnsl.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libelf.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libaio.so: wrong ELF class: ELFCLASS32
    ld: fatal: file /usr/lib/libc.so: wrong ELF class: ELFCLASS32
    ld: fatal: File processing errors. No output written to a.out
    -bash-3.00$
    -bash-3.00$ CC -xarch=amd64 foo.c
    -bash-3.00$ file a.out
    a.out: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped
    -bash-3.00$
    -bash-3.00$ cat foo.c
    int
    main()
    return 1 + 1;
    -bash-3.00$
    -bash-3.00$ ldd a.out
    libCstd.so.1 => /usr/lib/64/libCstd.so.1
    libCrun.so.1 => /usr/lib/64/libCrun.so.1
    libm.so.2 => /lib/64/libm.so.2
    libc.so.1 => /lib/64/libc.so.1
    -bash-3.00$
    I've installed whole solaris 10 except OEM distributions addons (IIRC the distro name correctly)
    Please let me know what else do you need to "debug" this issue.
    Thanks,
    Karel

  • SDK CVI compiler Warnings 64-bit

    It seems I am finding CVI Compiler warnings when compiling 64 Bit applications with SDK. I don't get these warning errors when I compile the same applications for 32 Bit.
    For example the CVI Compiler warning that I just found was found when I used SDK header file: "SetupAPI.h" with the typedef struct: SP_DEVINFO_DATA and SP_DEVICE_INTERFACE_DATA.
    The warning message I got was when I compiled the statements with the SetupAPI.h file included:
    SP_DEVINFO_DATA DeviceInfoData;
    /* warning message */
    DeviceInfoData.cbSize = sizeof(SP_DEVINFO_DATA);
    // Warning: Conversion from 'unsigned __int64' to 'DWORD' might lose data.
    /*warning message*/
    SP_DEVICE_INTERFACE_DATA did = {sizeof(did)};
    // Warning: Conversion from 'unsigned __int64' to 'DWORD' might lose data.
    When I compile these statements in 32-Bit I don't get these errors.
    Of course I can change the "SetupAPI.H" SDK Header supplied by NI but that defeats the whole purpose of why NI would distribute the header file in the first place.

    OK - Milan -
    I think you misunderstood what I was writing about.
    If you look at the SetupAPI.h file that is supplied by NI SDK with CVI 2010 at line 700 with the following typedef  struct:
    // Device information structure (references a device instance
    // that is a member of a device information set)
    typedef struct _SP_DEVINFO_DATA {
        DWORD cbSize;
        GUID  ClassGuid;
        DWORD DevInst;    // DEVINST handle
        ULONG_PTR Reserved;
    } SP_DEVINFO_DATA, *PSP_DEVINFO_DATA;
    The DWORD is defined as
    "typedef unsigned long"
     in cvidef.h (CVI 2010) header file.
    Yes I could change the SetupAPI.h inside the header file to change the type to be __int64 instead so that it works with 64 Bit. However, if other applications that are written for 32 bit will now be impacted if the SetupAPI.h is used with the __int64 data type DWORD.
    So what NI should so everywhere where they define "DWORD" that is used in the SDK they should have a conditional compile to set the type to "typedef __int64" in CVI 64-bit applications and
    "typedef unsigned long" in 32 Bit Applications.

  • 64-bit drivers for Windows AMD64?

    Windows XP 64-Bit Edition for AMD64 have been available for MSDN developers for quite awhile already.
    Where can we find any 64-bit beta drivers for this platform?
    Beta NVIDIA Windows Display Drivers for AMD64 are available for NVIDIA developers today according to this document:
    http://www.amd.com/us-en/assets/content_type/DownloadableAssets/NVIDIA_AMD64_Rev_Final_Aug03.pdf
    "Developer versions of the AMD64 NVIDIA display drivers are available to registered NVIDIA partners at http://www.nvidia.com."
    I hope MSI will release it together with other Windows AMD64 beta drivers, because a beta driver is much better than no driver at all...

    I know that, but MSI is a OEM partner of Nvidia and have access to all Nvidias beta drivers.  If MSI wants to release a beta Nvidia Windows display driver for AMD64 they can...

  • Solaris 10 64 bit for x86

    When i typed isainfo -kv the output is
    64-bit amd64 kernel modules. I think this means its a 32-bit OS anybody help when can i download 64bit?

    It isn't clear to me why you think you have a 32-bit system but there is one potential source of confusion that I can think of. A 64-bit Solaris system has a 64-bit kernel and drivers and is fully capable of running both 32 and 64 bit binaries; however, most of the system binaries are still 32 bit. So if you run "file /usr/bin/ls" you'll see a 32-bit executable even on a 64 bit system.
    If isainfo tells you it is a 64-bit system it is - even if most of the system binaries are compiled in 32 bit mode.

Maybe you are looking for